Best Practices Guide Best Practices for deploying a backup solution using IBM TIVOLI STORAGE MANAGER with EMC ISILON 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
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. EMC 2, 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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 2
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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 3
Executive Summary EMC Isilon scale-out NAS storage together with IBM Tivoli Storage Manager TM 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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 4
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 5
Abbreviation SMB CIFS NFS LAN SAN DAS NAS TSM Description Server Message Block Common Internet File System Network File System Local Area Network Storage Area Network Direct Attached Storage Network Attached Storage 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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 6
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 7
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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 8
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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 9
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 10
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: Backup Using IBM Tivoli Storage Manager with EMC Isilon 11
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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 12
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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 13
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 highspeed 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 2. IsilonNode02:/ifs/IBMTSMData/TSM01/n02 3. IsilonNode03:/ifs/IBMTSMData/TSM01/n03 TSM02 NFS Server Mounts: 1. IsilonNode01:/ifs/IBMTSMData/TSM02/n01 2. IsilonNode02:/ifs/IBMTSMData/TSM02/n02 3. IsilonNode03:/ifs/IBMTSMData/TSM02/n03 Backup Using IBM Tivoli Storage Manager with EMC Isilon 14
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 15
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 o 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. Instance Directory Name is using the TSM server instance name. e.g. E:\tsm\Server1\log; E:\tsm\Server2\log; /home/tsminst1; /home/tsminst2 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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 16
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 17
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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 18
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) Backup Using IBM Tivoli Storage Manager with EMC Isilon 19
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 writethrough 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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 20
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) Backup Using IBM Tivoli Storage Manager with EMC Isilon 21
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 22
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 sequentialaccess 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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 23
- 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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 24
Figure 11. TSM Storage Pool Figure 12. TSM Storage Pool s Volumes Backup Using IBM Tivoli Storage Manager with EMC Isilon 25
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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 26
- 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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 27
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 28
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: Backup Using IBM Tivoli Storage Manager with EMC Isilon 29
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 30
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 31
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 Backup Using IBM Tivoli Storage Manager with EMC Isilon 32
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 33
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. Backup Using IBM Tivoli Storage Manager with EMC Isilon 34