EMC Isilon and IBM Tivoli Storage Manager Best Practices · PDF fileBest Practices Guide Abstract This white paper outlines best practices for deploying EMC Isilon scale-out storage

Best Practices Guide

Abstract

This white paper outlines best practices for deploying EMC Isilon

scale-out storage with IBM Tivoli Storage Manager for a flexible and scalable backup solution.

May 2014

Best Practices for deploying a backup solution

using IBM TIVOLI STORAGE MANAGER with

EMC ISILON

Backup Using IBM Tivoli Storage Manager with EMC Isilon

2

Copyright © 2014 EMC Corporation. All Rights Reserved.

EMC believes the information in this publication is accurate as of

its publication date. The information is subject to change without notice.

The information in this publication is provided “as is.” EMC

Corporation makes no representations or warranties of any kind

with respect to the information in this publication, and specifically disclaims implied warranties of merchantability or

fitness for a particular purpose.

Use, copying, and distribution of any EMC software described in this publication requires an applicable software license.

For the most up-to-date listing of EMC product names, see EMC

Corporation Trademarks on EMC.com.

All other trademarks used herein are the property of their

respective owners.

EMC2, EMC, the EMC logo, Centera, Isilon, OneFS, and SmartLock are registered trademarks or trademarks of EMC

Corporation in the United States and other countries. All other trademarks used herein are the property of their respective

owners.

Part Number h13168


3

Table of Contents

Executive Summary ........................................................................................ 4

Audience ..................................................................................................... 5

Terminology ................................................................................................. 5

Solution Components .................................................................................... 6

Architecture Overview .................................................................................... 6

Best Practices ................................................................................................ 8

Lab Configuration ......................................................................................... 8

Networking ................................................................................................ 11

Basic ..................................................................................................... 11

Advanced ............................................................................................... 12

Performance .............................................................................................. 13

Basic ..................................................................................................... 13

Advanced ............................................................................................... 16

Configuration ............................................................................................... 17

Configuration Overview ............................................................................... 17

Isilon Storage Platform Configuration ............................................................ 17

Basic ..................................................................................................... 18

Advanced ............................................................................................... 18

IBM Tivoli Storage Manager Configuration ...................................................... 21

Basic ..................................................................................................... 21

Advanced ............................................................................................... 27

Troubleshooting ........................................................................................... 32

TSM Server Instance Configuration Issue ....................................................... 32

Conclusion .................................................................................................... 33

About EMC .................................................................................................... 34


4

Executive Summary

EMC® Isilon® scale-out NAS storage together with IBM Tivoli Storage ManagerTM

provides a comprehensive, flexible and scalable backup solution that lets enterprises

of all sizes address their backup needs; from laptops to mainframes, all from a single

console. This paper describes the best practices and solution-specific configuration

steps for deployment of Tivoli Storage Manager with Isilon for both basic and

advanced deployments.

Backup challenges with traditional storage

1. Compounding effect of backups

Each year organizations are generating more data and keeping that data for longer.

This growth can be exponential, since traditionally many full backup copies are kept

weekly, monthly, and yearly. For example: If the most recent weekly backups are

kept for 8 weeks, monthly backups for 10 months (covering the remainder of the

year), and yearly backups for 7 years, then one file would have 25 copies just using

the backup algorithm. Using this example, just 40 TB of new data would need 1 PB of

storage. There are mechanisms to reduce some of the common data, like

compression, deduplication, and snapshots, but portions of the data will be unique or

not easily reduced.

This compounding growth affects the cost of tape even more, since many of these

data reduction mechanisms are not available, native tape drive compression is only

supported by tape. In addition, there are many often overlooked issues that need to

be considered when using tape – the cost of secure off-site storage, cost to

periodically retrieve backups from storage to perform test restores as needed for

compliance or business policy, and the risk of not being able to read older tapes if too

many tape drive generations have passed.

2. Management overhead

Individually monitoring performance and free space on traditional RAID-based

volumes / LUNs becomes a huge burden. The constant juggling and adding of new volumes / LUNs when capacity or hardware limits are reached consumes more and

more time, and each storage change often requires the application’s configuration to be updated as well.

3. Refresh cycle and data migration

The inevitable, and often overlooked, hardware refresh every 3 to 5 years will more

than likely take up many nights and weekends, data center resources, and budget

with traditional RAID-based storage systems. With extensive planning, a complete

re-evaluation of performance and capacity requirements, including future needs out

to 3 or more years; they will need a new infrastructure to be stood up alongside the

old infrastructure to allow the data to be migrated, likely with one or more outage

windows. Provisioning data center rack space, power, cooling, and network

infrastructure for this type of hardware refresh can be very expensive and time

consuming.


5

Backup Solutions with Isilon and Tivoli Storage Manager

Isilon scale-out NAS technology removes the hurdles of multiple backup copies,

management overhead, application reconfiguration, and data migration; so you can

focus on your organization’s backup and archive strategy.

EMC Isilon OneFS®, the intelligence behind the Isilon scale-out NAS, combines the

three layers of traditional storage architectures—file system, volume manager, and

data protection—into one unified software layer, creating a single intelligent file

system that spans across all nodes within a cluster. The application only needs to be

configured once to use the single namespace provided by OneFS. New cluster

capacity can be added in 60 seconds and is immediately available for use by the

application without any manual intervention. To eliminate performance and capacity

hot-spots, and the juggling of volumes / LUNs, Isilon automatically distributes clients,

file data, and free space across the entire cluster. With Isilon’s utilization rate of over

80%, not achievable with RAID-based storage systems, fewer hard drives are needed

to satisfy the capacity demands while providing a comparable or higher level of data

protection. The ability to grow capacity to over 20 PB within a single cluster and

push-button retire older hardware reduces and simplifies data migration on hardware

upgrades and eliminates the need to support two infrastructures simultaneously. This

saves valuable data center rack space, power, cooling, and network infrastructure,

not to mention time.

Tivoli Storage Manager is a data protection platform that gives enterprises a single

point of control and administration for storage management needs. It enables

outstanding efficiency, simplicity and scalability for virtual, physical and cloud backup

environments of all sizes. It can protect a wide range of systems from a single

administration interface; including virtual machines, file servers, email, databases,

mainframes, and desktops. Any number of TSM components can be deployed to

meet the needs of the organization, without per-product licensing charges, as

licensing is only based on the amount of data being managed; which can be kept low

through the use of built-in source and target data deduplication, there is no charge

for duplicate copies of data.

Basic best practices enable quick, easy, and straightforward deployments using the

fewest settings to get you started. The advanced best practices identify opportunities

to configure the system for performance, scalability, or highly secure environments

for a more optimized deployment model. This requires a high level of knowledge,

support, and time to plan the deployment of all the components in advance.

Audience

This document is intended for administrators who will deploy and configure Isilon with

Tivoli Storage Manager. The assumed level of technical knowledge for the devices and

technologies described in this document is high.

Terminology

The abbreviations used in this document are summarized in the Table 1.


6

Abbreviation Description

SMB Server Message Block

CIFS Common Internet File System

NFS Network File System

LAN Local Area Network

SAN Storage Area Network

DAS Direct Attached Storage

NAS Network Attached Storage

TSM Tivoli Storage Manager

Table 1. Abbreviations

Solution Components

The following solution components are described in this document:

IBM Tivoli Storage Manager v6.3.4.200 for Windows and EMC Isilon scale-out

NAS with OneFS v7.1

IBM Tivoli Storage Manager v6.3.4.0 for Linux and EMC Isilon scale-out NAS

with OneFS v7.1

IBM Tivoli Storage Manager v6.3.4.0 for AIX and EMC Isilon scale-out NAS with OneFS v7.1

Architecture Overview

Tivoli Storage Manager (TSM) is an enterprise-wide storage management application that includes server and client components. The server component consists of a

server program, which provides backup, archive, and space management services to the clients, and server storage, which is a data repository that can be a DAS, SAN, or

NAS device. This white paper will focus on a TSM backup solution that writes data to

an Isilon NAS that is connected to the TSM server over a LAN using SMB/CIFS and NFS services.

An overview of the logical flow of backup and archive data between the TSM servers and clients, and Isilon scale-out storage is provided in Figure 1.


7

Figure 1. Logical Flow Overview (CIFS / NFS)

Figure 2 provides an overview of the logical architecture that shows the network connectivity

between the TSM servers and Isilon cluster nodes. The Isilon cluster defined as a storage pool

used by the TSM servers which is accessible over SMB/CIFS by Windows TSM Servers and over NFS by Linux and AIX TSM Servers. With this configuration, the storage pool never needs to be

updated. When capacity is added to the Isilon cluster, the TSM servers immediately see the additional capacity without intervention; nodes can be added to an Isilon cluster in as little as

60 seconds with just a few clicks. This solution is well suited for IT environments that would like to virtualize their TSM servers as they are able to communicate and manage the backup

target storage device over a LAN.


8

Figure 2. Logical Architecture Overview

Adding capacity to a TSM environment that is using traditional RAID-based storage, whether it

is a DAS-, SAN-, or other NAS-based device, requires many configuration steps on both the

storage system and the TSM configuration. The storage system needs to be manually configured to provision the additional storage on existing or new volumes / LUNs. The TSM

configuration would need a new volume created, and a storage pool modified or created to utilize the new capacity. These are time consuming tasks that are eliminated when Isilon

storage is used instead

Best Practices

Lab Configuration

This whitepaper is based on the best practices demonstrated by using the following

configuration which can be scaled and adapted for your needs.

1. TSM Server Instance

Three single instance TSM servers were used for this testing. The first

two servers were installed on a VMware vSphere ESXi Server infrastructure. The OS for the first VM was Windows 2008 R2 Server


9

and the second one was RHEL 6.3. The third TSM server was installed

on an IBM Power Server with AIX 6.1.

2. Tivoli Integrated Portal (TIP)

TIP was installed on the same VM as the TSM Server Windows machine. All three TSM Servers were registered to and managed from

this centralized Administration Center. Figure 3 shows the TIP GUI and

Figure 4 shows the command line interfaces that are running on the TSM Server Windows machine.

Figure 3. Manage Servers in TIP User Interface


10

Figure 4. TSM Command Line Administrative Interfaces run from a

centralized machine

3. TSM Backup-Archive (BA) Client

An example of a TSM BA Client installed on a Windows, is shown in

Figure 5. TSM also support AIX, HP-UX, Linux, Mac OS, and Solaris as BA clients.


11

Figure 5. TSM Backup-Archive Client

Networking

The networking sections that follow provide guidance and best practices to design and deploy the network connectivity and communication pathways for your environment.

Basic

In this section we will discuss the basic information you should know to avoid firewall,

services, permissions, and bandwidth requirements, and understand your connectivity options.

Firewall

The following list of TCP ports must be open on the TSM Server:

TSM Server (Windows) with CIFS Configuration – 445, 137, and 139

TSM Server (Linux and AIX) with NFS Configuration – 22 or 23

Network Services

The following network services / protocols are required on the TSM Server:

TSM Server (Windows) with CIFS Configuration:


12

o Enable Windows SMB Protocols – File and Print Sharing

o Disable User Account Control (during installation process)

TSM Server (Linux and AIX) with NFS Configuration:

o Enable Secure Shell (SSH) / Telnet

User ID for TSM Server Instance

The TSM Server Instance User ID needs to be created to own the server instance.

In Windows platform, this user account must have administrative authority on the

system. This instance user id must be added to the following user groups: Administrators and DB2ADMNS groups.

In Linux and AIX platforms, this instance user ID must have ownership or read/write access authority to all directories that we create for the database and the recovery

log. The standard way to run the server is under this instance user ID.

With this instance user ID we need to log in to the system and create the required

directories for the TSM instance (instance directory, database directories, active log

directory, archive log directory, log mirror directory and failover archive log directory).

Bandwidth

Most deployments will use a pair of bonded 10 GE connections between the TSM servers and Isilon cluster nodes for maximum bandwidth and high availability,

including the use of two different Ethernet switches to avoid single points of failure.

Alternatively, two or four bonded 1 GE connections can be used when that provides sufficient bandwidth and/or a 10 GE infrastructure is not available.

Advanced

In this section we will discuss the advanced information you should know regarding

firewall ports.

Tivoli Integrated Portal (Administration Center) Firewall Ports

Server Port Comments

Tivoli Integrated Portal 16310 (default) HTTP

Tivoli Integrated Portal 16311 (default) HTTPS

Table 2. Advanced Firewall


13

Performance The performance sections that follow provide guidance and best practices to ensure the health

and performance of the TSM components and their resources.

Basic

In this section we will discuss the basic information you should know about the resource requirements for the TSM components and their performance related

information.

Tivoli Storage Manager Server Configuration

Operating System

Tivoli Storage Manager Servers are optimized for and perform best on 64-bit hardware and operating systems, which enables them to address greater amounts of

memory. This is especially advantageous for heavy workload environments with multiple instances, data deduplication, and replications.

The Tivoli Storage Manager on Windows platform requires one of the following operating systems:

Microsoft Windows Server 2008: Standard, Enterprise, or Datacenter x64 Edition

(64-bit)

Microsoft Windows Server 2008 R2: Standard, Enterprise, or Datacenter Edition

(64-bit)

Microsoft Windows 2012 (64-bit)

The Tivoli Storage Manager server on Linux x86_64 requires one of the following operating systems:

Red Hat Enterprise Linux 5, Update 3 or later

Red Hat Enterprise Linux 6

SUSE Linux Enterprise Server 10, Service Pack 2 or later

SUSE Linux Enterprise Server 11

The Tivoli Storage Manager server on AIX platform requires one of the following

operating systems:

AIX V6.1 (64 bit) – minimum TL2

AIX V7.1 (64 bit)

Processor

TSM for Windows and Linux x86_64 requires an AMD64 or Intel EMT-64 processor. TSM for AIX requires POWER4, POWER5, POWER6, or POWER7 systems computer

(64-bit)

Memory


14

IBM recommends a minimum of 12GB of RAM for TSM servers and 16GB of RAM when

data deduplication is used. Node replication with data deduplication requires a minimum of 64 GB of RAM.

For heavily used servers, IBM recommends a minimum of 32GB of RAM for TSM server, as 32 GB of RAM or more enhances performance of the Tivoli Storage

Manager Server database inventory.

For TSM server with multiple TSM instances, it requires the above-mentioned memory multiplies by the number of instances.

Network

For the case of normal backup and restore over the LAN, the network is used by TSM

to:

Send Backup and Restore Control Information

Send Backup and Restore Data

To enhance this backup and restore performance, we can allocate a dedicated high-

speed back-end network to interconnect the TSM Server and Isilon storage target.

We can also reduce the network bottleneck between the TSM server and clients by designing the backup infrastructure such that the TSM Server frontend network

interface resides on the same network segment / subnet as the clients to eliminate network hops.

SmartConnect is a feature in the Isilon cluster that allows CIFS or NFS requests to be intelligently distributed across the entire cluster increasing aggregate throughput, and

providing load balancing and high availability.

In Windows environments, the UNC path to an Isilon cluster SMB share should be

used to ensure Windows performs a DNS resolution each time and thereby allows the

Isilon cluster to load balance new connections.

In NFS environments, the same is true for Isilon cluster NFS exports. If greater

control is required to ensure maximum performance between the Isilon cluster and the TSM servers, a directory can be created for each TSM server, with a sub-directory

for each Isilon cluster node to enable the TSM servers to define a mount point for each Isilon node using a unique directory. For example, for maximum performance

over NFS with a three node Isilon cluster, each TSM server would have three mounts, one per cluster node using a unique NFS path.

TSM01 NFS Server Mounts:

1. IsilonNode01:/ifs/IBMTSMData/TSM01/n01



TSM02 NFS Server Mounts:





15

Three primary network design options exist for connectivity between the TSM servers

and Isilon cluster nodes.

1. Designed for lower cost: If switch ports are limited and bandwidth needs can

be met with less than all the Isilon cluster nodes, the excess nodes can remain disconnected on the external Ethernet interfaces. This is possible due to the

internal InfiniBand connections that enable all of the nodes to continue to

communicate and access resources, including capacity. At a minimum, it is recommended to connect at least two different nodes in the cluster to two

different Ethernet switches to avoid a single point of failure. The use of 10 GE connectivity may ease the bandwidth limitation of this design, though its

usefulness is limited to smaller deployments.

2. Designed for ease of management: Connect all Isilon cluster nodes to two

different Ethernet switches and allow SmartConnect to provide load balancing and high availability.

3. Designed for maximum performance: This would be the same as # 2 above,

except NFS mounts are configured as described previously in this Network section, for greater control and maximum performance.

Storage

IBM recommends the following minimum hard disk space requirements for TSM on

Windows, Linux and AIX platforms:

TSM Server on Windows:

At least 3 GB of free disk storage (for a typical installation)

200 MB temporary directory space

2 GB partition size in the C:\ drive

300 MB in the instance directory

TSM Server on Linux and AIX:

5 MB for the /var directory

30 MB for the /opt directory if we create mount points

2 GB for the /opt/tivoli/tsm directory

390 MB for the /tmp directory

300 MB for the /usr directory

2 GB in the home directory.

Tip: Expect to use more space for problem determination.

On top of those minimum disk spaces, significant additional disk space is required for database and log files. The size of the database depends on the number of client files

to be stored and the method by which the server manages them. The default active log space is 16 GB, the minimum that is needed for most workloads and

configurations. Allocate at least three times the active log space for the archive log (48 GB). Ensure that you have sufficient resources if you are using data deduplication

or expect a heavy client workload.


16

To optimize the performance for TSM, it is recommended to have the database,

archive log and active log on different physical volumes.

For example:

Database directories:

E:\tsm\db001

F:\tsm\db002

G:\tsm\db003

H:\tsm\db004

Active Log directory:

I:\tsm\log

Archive Log directory:

J:\tsm\archlog

Advanced

In this section we will discuss the advanced information you should know regarding multiple TSM server instances.

Multiple TSM Server Instances on a Single System

More than one TSM server instance can be created on a single system. This is to

achieve higher resource utilization for the powerful machine by loading more instances into a single machine. With this multiple instances configuration it will also

help IT department to reduce number of hardware and licensing costs, energy costs,

and to have higher level of consolidation for backup infrastructure.

Basic requirements for this multiple TSM instances:

Each server instance has its own instance directory, and database and log directories.

Naming recommendation:

o Database instance name:

For Windows: the database instance name is the name of the TSM server instance name. For example: Server1, Server2.

For Linux and AIX: the database instance name is the name of

instance user ID. For example: tsminst1.

o Instance Directory Name is using the TSM server instance name. e.g.

E:\tsm\Server1\log; E:\tsm\Server2\log; /home/tsminst1; /home/tsminst2

o Database name is always TSMDB1 for every server instance. This name cannot be changed.

Multiply the memory and other system requirements for one server by the number of instances planned for the system.


17

Configuration

Configuration Overview

An overview of the configuration steps for a IBM TSM and EMC Isilon OneFS scale-out

storage deployment is provided in Figure 7. The sections that follow provide guidance on best practices or required settings for each step, where applicable.

Figure 6. IBM TSM and Isilon OneFS Configuration Workflow

Isilon Storage Platform Configuration The sections that follow provide configuration guidance and best practices for configuring the Isilon cluster.


18

Basic

In this section we will discuss the basic requirement for creating the backup directory on the Isilon cluster.

Create TSM Backup Directory

In a typical IT environment, it is common to have multiple applications utilizing a

shared central enterprise storage system, such as an Isilon cluster. To ensure

simplified storage and application management, it is a recommended best practice to create directories using a naming convention that easily represents the application

(for example, /ifs/IBMTSMData). In this way, it should be clear which group owns the data, if capacity or other questions arise.

When creating the CommVault backup directory, ensure the user account used by TSM has Full Control permissions on the directory.

The default /ifs share or export can be used to access the directory (for example, \\IsilonClusterName\ifs\IBMTSMData)

Advanced

In this section we will discuss the advanced options of creating an IBM TSM specific share or export on the Isilon cluster.

Create TSM Specific Share or Export

Depending on the cluster configuration and other workloads being placed on the

cluster, it may be helpful to create a specific share or export for TSM. This could be

useful to more easily expose the directory being use for this purpose, if not immediately under the /ifs directory, or to more clearly show the workloads on a

cluster from a visibility / manageability perspective. This is facilitated by the additional details that can be recorded within the share or export description on the

Isilon cluster.

When creating the TSM share or export, ensure the user account used by the TSM

server has the appropriate permissions on the share.

For example, the following CLI command can be used to create the IBM TSM directory

and its SMB share.

isilon-1-1# mkdir /ifs/IBMTSMData

isilon-1-1# isi smb shares create –name=IBMTSM –path=/ifs/IBMTSMData –

browsable=true –description=”Share for IBM TSM backups, managed by the

Backup and Archive IT Group”

Isilon File Sharing


19

With its build-in multi-protocol support, Isilon OneFS provides the ability to share

directories and files to Windows client machines through SMB and to Linux client machines through NFS.

Create CIFS/SMB Share

Refer to the Isilon OneFS Web Administration Guide for complete configuration

procedures.

Overview:

1. Enable the SMB Service, if not enabled already (see Figure 8)

2. Create an SMB share

3. Add the TSM instance id user (tsmadmin) to the SMB Share with Full Control

permissions

4. Test this SMB share by browsing to it on the TSM Server (Windows Platform)

Figure 7. Isilon SMB WebUI

Create NFS Export

Refer to the Isilon OneFS Version Web Administration Guide for complete configuration procedures.

Overview:

1. Enable the NFS service, if not enabled already (see Figure 9)

2. Create an NFS export

3. Add TSM Server IP Address in the NFS client list and allow Read-Write access

4. Map users to user name ‘nobody’

5. Test this NFS export by mounting it on the TSM Server (Linux or AIX platform)


20

Figure 8. Isilon NFS WebUI

Write Cache

OneFS SmartCache

Isilon OneFS includes a write caching feature called SmartCache that accelerates the process of writing data to the cluster. When this feature is enabled (is enabled by

default and is shown in Figure 10), OneFS writes data to a write-back cache instead of

immediately writing to disk. This enables writes to be performed at a time that is convenient and allows more writes to be batched together. To guard write

transactions against sudden power loss or other catastrophic events, all writes are mirrored to participant nodes’ NVRAM to satisfy the file’s protection requirement

before write acknowledgements are returned, and NVRAM is dual-battery backed on every Isilon cluster node.

TSM Storage Requirement

Data in TSM storage pools, database volumes, and log volumes are interdependent.

TSM requires that the data written to these entities can be retrieved exactly as it was

written. Also data in these entities must be consistent with one another. I/O operation results must be reported synchronously and accurately. For storage systems that use

caches of various types, the data must be permanently committed. TSM uses write-through and file-sync flags to ensure data are written synchronously.

SmartCache interprets this write-through and file-sync flags as synchronous writes and is able to utilize the SmartCache mechanism. Isilon is able to support the TSM

storage requirement through the protection mechanisms described above, so regardless of which node is processing the write request, all successfully writes are

protected and quickly acknowledged. This extra level of protection is a key reason

why Isilon versus other NAS solutions can be used as a reliable backup target for TSM.


21

Figure 9. Isilon SmartCache for file system is Enabled

IBM Tivoli Storage Manager Configuration The sections that follow provide configuration guidance and best practices for configuring the IBM TSM environment.

Basic

In this section we will discuss the basic best practice for configuring the TSM storage

pools, domain policy, and client node configuration.

TSM Storage Device Configuration

TSM supports backup to NAS device in two different configurations:

DISK (Random Access) device type

FILE (Sequential Access) device type

Both of these device types can be integrated as a backup solution by creating two

different storage pools:

Primary Storage Pool with DISK (Random Access device class type)

COPY Storage Pool with FILE (Sequential device class type)


22

Comparing DISK and FILE Device Type

Primary Storage Pool

TSM supports both DISK and FILE device types for Primary Storage Pool. Both device types have differences in their method of handling the data stored and accessed with

their related advantages and disadvantage. TSM provides a documentation to

compare both device types in “IBM Tivoli Storage Manager – Administrator’s Guide”.

Some of the differences are highlighted here:

1. Minimum Write I/O Block Size and Space Allocation – Tracking functions.

In a FILE device type, data is written to the storage as a 256 KB block I/O.

This 256 KB is the minimum size of I/O written to a volume, regardless the actual size of the data. With this characteristics, backup up of a large number

smaller sized objects (files or directories) to FILE device type storage pool may not be as efficient or provide as much performance as a DISK device. Though

in mixed environments, a moderate amount of larger sized objects (files or

directories) can sufficiently offset the efficiency and performance related to smaller sized objects.

On the other hand, the DISK device type uses disk blocks for space allocation and tracking and the FILE device type uses volumes. Space allocation and

tracking by blocks uses more database storage space, and requires more processing power than space allocation and tracking by volume. This means

that larger sized objects (files or directories) are more suitable to a FILE device type, in terms of TSM’s database storage space and backup data

location tracking.

To mitigate the performance degradation for backup large number of smaller objects, TSM provides aggregation parameter setting – TXNGROUPMAX. When

the value of this TXNGROUPMAX parameter is increased, TSM will increase the size of aggregation of objects (including files) to be backed up as a single

transaction.

2. Volume Configuration

The FILE device type supports a MAXSCRATCH parameter that defines the maximum number of scratch volumes in a storage pool. This scratch volume

mechanism provides an easier way to manage and configure volumes, as it will

automatically prepare new scratch volumes as needed.

3. Aggregate Reconstruction and Recovery of Disk Space

The DISK device type does not support aggregate reconstruction and may lead to wasted space and fragmentation after files are deleted or migrated.

The FILE device type supports aggregate reconstruction as a part of Reclamation, at which time the reclaimed space can be reused.

4. Multi-Session Restore for NQR

The FILE device type supports multi-session restore for No-Query Restore

operations. This will increase the speed of restore operation. This multi-session

restore allows a restore session per sequential-access volume.


23

The DISK device type does not support multi-session restore for NQR. It only

allows one session for all random-access volumes.

5. The best practice for performance and reduced processing on the TSM server

is to select FILE device type in TSM with Isilon storage. The sequential write (backup) and read (restore or verify) functions in backup to disk with TSM will

perform very well with Isilon clusters as the data is written and read across

multiple nodes which increases sequential performance. Read-ahead across multiple nodes is another key factor in attaining the highest restore

throughput.

Based on the comparison and also the direction for the TSM new functions and its

integration with the storage target, we can see that configuring the FILE sequential-access type as the Primary Storage Pool on an Isilon cluster is a more strategic

solution.

Copy Storage Pool and Active-Data Pool

Since the DISK device type is not supported for Copy Storage Pool and Active-Data Pool, we use the FILE device type for these types of Pools.

Create DISK device type

1. In TSM Administration Center (TIP), select action View Storage Pool.

2. Select Create a Storage Pool and provide a name.

3. Select Random Access for the Storage Pool type.

4. Click Next and then create a new disk volume

5. Specify volume name and volume size. We use a name for a disk volume with a

path to the SMB/CIFS or NFS share (e.g.\\isilon\IBMTSM\DISKVOL.001 or /ISILONNFS/DISKVOL/DISK001).

Create FILE device type

1. Create Device Class (FILE for sequential volume on disk)

- Select Storage Devices menu in the TIP Administration Center GUI

- Select View Device Classes

- Select Create Device Class

- Define the Device Type as FILE

- Provide a name and specify the path to the directory for storing files (UNC path). (For example: specify UNC \\isilon\IBMTSM\CopySeqBackup ; Set

Mount Limit to 5 and Maximum File Size to 20 GB).

2. Create Storage Pool


24

- Select Storage Devices menu and then View Storage Pools

- Select Create a Storage Pool

- Specify Storage Pool name (e.g. ISILON-COPY-POOL)

- Specify Storage Pool Type (e.g. Sequential access). Set as Copy (in our testing, this FILE type storage device is used for COPY Storage Pool)

- Select Device Class Name (e.g. ISILON-FILE)

- Specify Maximum number of scratch volume. (e.g. MAXSCRATCH= 50)

- In our test, we did not use the TSM deduplication

3. Create volume

- Select View Storage Pool menu

- Select ISILON-COPY-POOL

- Select Volumes

- Select action Add Volume

- Specify Volume Name, Size and Number of Volumes

Figure 10. TSM Device Classes


25

Figure 11. TSM Storage Pool

Figure 12. TSM Storage Pool’s Volumes


26

Create Policy Domain

1. Select Policy Domains menu and then View Policy Domains

2. Select Create a Policy Domain

3. Specify a name (e.g. ISILON_DISK_POLICY)

4. Specify default management class setting for backup data to use ISILON-DISK-

POOL

5. Set the number of file versions to keep (e.g. 2 file versions)

6. Set number of days to keep inactive versions (e.g. 7 days)

7. We can assign the client node to this policy domain at later stage (when we create a client node)

Figure 13. TSM Policy Domains

Client Node Configuration

1. Create Client Nodes (Using TIP TSM Administration Center GUI)

- Select Client Nodes and Backup Sets menu

- Select Action => Create a Client Node

- Specify the Server that we want this client node to connect

- Specify the Policy Domain


27

- Specify name and password

Figure 14. TSM Client Nodes

2. Client Node configuration on client machine

- Run the Backup-Archive GUI and run the setup Wizard

- Configure the client node connection to the server

Advanced

In this section we will discuss the advanced policy, device class, and storage pool settings.

TSM Backup Setting in Policy Domains

Specific backup settings can be configured in TSM Policy Domains. These settings are configured based on company policies. Examples for those settings are related to

backup versions:

Number of File Versions to keep: specify how many versions of a file to keep

Number of Days to keep Inactive versions: specify how many days to retain


28

Figure 15. TSM Policy Domain – Backup Versions

Multiple versions of files are useful when users continually update files and sometimes

need to restore the original file from which they started. The most current backup version of a file is called the active version. All other versions are called inactive

versions.

When a backup policy requires keeping all versions for point in time data restore, the

option “No Limit” is applied for “How many different versions of the file should be kept”.

This applied backup policy can be seen in the Administration Center as well as in

Backup-Archive Client program.


29

Figure 16. TSM BA-Client – Policy

TSM Device Class

Some specific backup device settings can be configured in TSM Device Class settings:

Mount Limit:

TSM uses this setting to restrict the number of mount points (volumes or files)

that can be concurrently opened for access by server storage and retrieval operations.

When selecting a mount limit for this device class, consider how many Tivoli Storage Manager processes we want to run at the same time. To optimize

performance, match the mount limit to the number of volumes.

There are some guidelines to define this parameter:


30

1. TSM supports this mount limit parameter up to 4096

2. Default value is 20

3. Some considerations:

a. Define this value based on the number of TSM processes that are allowed to run at the same time.

b. When the number of TSM processes is higher than the defined

value (e.g. when TSM attempts to access more volumes than the Mount Limit value), causes the requester to wait.

c. When the value is higher than the number of storage pool volumes, it is still limited by the number of available volumes.

d. TSM will cancel some processes to run higher priority processes. For example, TSM can cancel a reclamation process if no mount

points are available to perform a client restore. Also, if all available mount points are being used by higher priority

processes, then lower priority processes must wait until a mount

point becomes available.

Maximum File Size:

TSM uses the Maximum File Size / Maximum Volume Capacity (in

Administration Center GUI) or MAXCAPACITY (in Command Line) to restrict the maximum size of volumes (files) associated with a FILE device class. This size

parameter should not exceed the maximum supported size of a file on the target file system.

When backup data size on a volume has reached this value, TSM will store any

new data on a different volume or use this condition as a trigger to create a new volume.

There are some guidelines to define this parameter:

1. Minimum supported size is 1 MB.

2. Default value is 2 GB.

3. Maximum supported size is the maximum supported size of a file on the

target file system.


31

Figure 17. TSM Device Class – Settings

Primary and COPY Storage Pool

A COPY Storage Pool can be used to backup one or more Primary storage pools. COPY storage pools reduce the potential for data loss due to media failure by

maintaining duplicate copies of files. If the primary file is not available or becomes corrupted, the server uses the duplicate file from a copy storage pool.


32

Figure 18. Primary and Copy Storage Pools

TSM Storage Pool – Maximum Scratch Volumes

Maximum Scratch Volume (MAXSCRATCH) parameter specifies the maximum number

of scratch volumes that is available for the TSM server to request from a specific storage pool. TSM server will acquire and define new scratch volumes as needed.

This MAXSCRATCH value can be defined up to 100000000. The available storage space of the target system must be considered in defining this value.

MAXSCRATCH value can be used to estimate the total size of available volume in a storage pool and also the capacity of that storage pool.

Troubleshooting

TSM Server Instance Configuration Issue

Once TSM software has been installed on a server, the next step is to configure TSM

server Instance.

When the instance configuration process is not successful, verify the following:

1. Disk Space for storing TSM Database and Log Files.

The default initial minimum disk space requirement for the active log

files is 16 GB. When the disk allocated to this TSM database log files has a smaller free disk space, the configuration will not be successful.

To resolve this issue, point the active log files directory to a bigger


33

disk volume during the configuration process (either via configuration

wizard or manually using the dsmserv format utility)

2. Windows User Account Control (UAC) Setting

The instance configuration process is performed by logging in to the

server as the instance user ID (user ID that owns the TSM server

instance), which in most cases is different than the Administrator user ID, and the Windows User Account Control must be disabled for that

user during the configuration process.

When the UAC is enabled, it prevents unauthorized changes that

require administrator-level permission to the server, including the changes performed by the instance user id during the instance

configuration process.

Conclusion

The accelerating amount of data being generated today can have an exponential

effect on the amount of space needed for backups. This creates unprecedented challenges on storage systems not built with scale-out as a core component of their

technology. Choosing the right storage solution that provides ease of management, automated distribution, seamlessly scales, saves valuable data center resources,

helps achieve required SLAs, and turns the inevitable hardware refresh / migration into a simple push-button affair is critical to providing peace of mind to IT

organizations already stretched thin on resources.

Using the basic deployment method you are able to implement the IBM TSM and EMC

Isilon environment with the least amount of effort, provide good resiliency and

performance, and have the information necessary to avoid common issues. The advanced deployment method provides additional information to customize,

administer, and optimize backup performance.


34

About EMC

EMC Corporation is a global leader in enabling businesses and service providers to transform their operations and deliver IT as a service. Fundamental to this

transformation is cloud computing. Through innovative products and services, EMC accelerates the journey to cloud computing, helping IT departments to store,

manage, protect, and analyze their most valuable asset—information—in a more

agile, trusted, and cost-efficient way. Additional information about EMC can be found at www.EMC.com.

http://www.emc.com/

Documents

EMC Isilon and IBM Tivoli Storage Manager Best Practices · PDF fileBest Practices Guide Abstract This white paper outlines best practices for deploying EMC Isilon scale-out storage