VTL Best Practices Guide
This document provides Best Practice guidelines to help ensure optimal performance nd of the Data Domain Virtual Tape Library (VTL) in backup environments and lso to ensure ease of supporting and maintaining the product.
- Content All Data omain systems
- All Software Releases upporting VTL
- VTL Protocol
- Third Party Backup Application ("BA") such as Networker, TSM, etc.
1. Basic Guidelines to avoid poor performance
- It is critical that you ensure that a VTL qualifier has been completed for your installation, and verified for proper operation. Use of unsupported HBAs, drivers, etc are a common source of problems.
- Attempt to keep the Data Domain system less than 85% full. Filesystem Cleaning and other operations will be faster and more efficient when the system has enough available disk to perform these important tasks.
- Try to schedule Filesystem Clean (also known as Garbage Collection or filesystem cleaning) to run during times when active backups are not running.
- The default Filesystem Clean schedule is sufficient in the vast majority of environments. Consult the document "Scheduling Cleaning on a Data Domain System: Best Practices" to better understand this process. If you still feel there is reason to alter the default schedule to have Filesystem Clean run more often, please contact Data Domain Support to discuss.
- Don't schedule Replication to overlap with your active VTL backup window. Both processes require substantial resources and
will complete faster if run separately rather than concurrently.
- Never use encryption, multiplexing, or pre-compression or client-side deduplication from the client BA (ie. Networker, TSM), as they will greatly reduce the compression factor obtained on the Data Domain system. Perform these activities on the Data Domain system only. Some backup applications turn on these features by default (ie. HP Data Protector defaults to multiplexing), so please check that all of these are turned OFF for your application.
- Although the Data Domain system may offer higher limits in configuration options (number of streams, throttling, replication, etc), use of more moderate configurations will often offer the best overall performance.
- Be certain that you read and understand all alerts from the Data Domain system. If you don't understand an alert, please call support for clarification.
- Don't just use the default pool for everything. Create at least one other pool and create all tapes in the pool(s) you created. If you currently use replication (or may in the future), it is important to create and use between 5 and 10 replication contexts (ie. a VTL pool) for improved performance.
- Consult the appropriate compatibility matrix to ensure that your specific components are compatibile with VTL.
2. VTL Components
i. It is required that the FC initiator port must be dedicated to only Data Domain VTL devices.
ii. Only initiators that need to communicate with a particular set of VTL target ports on a Data Domain system should be zoned with that Data Domain system.
iii. Create a useful alias for every initiator you zone and connect to the Data Domain system, preferably including the hostname and port in the alias name.
iv. Use only 1-to-1 zoning; create zones on your Fibre Channel switch composed of only one initiator and one target per zone.
b.Slots – The number of slots/drives a library should have will be dictated by how many simultaneous backup and restore streams will be running. Drive counts will also be constrained by the configuration and overall performance limits of your particular Data Domain system. Slot counts will typically be based on how many tapes will be used over a retention policy cycle.
Refer to the Data Domain Integration documentation for your specific Backup Application to determine if CAPs (Cartridge Access Points) need to be emulated for your particular environment. See "References" section for links.
There can be only one changer per VTL.
In many cases, the changer model you should select depends on your specific configuration:
Use the RESTORER-L180 library emulation when using Symantec Backup software
Use the TS3500 library emulation when using IBM System i platform
You can also use the TS3500 library emulation when using TSM 6.2 on AIX 6.1 and AIX 5.3 platforms.
Most other installations should use the L180 library emulation (non-Symantec, non-IBM system i)
i.auto-offline: If a tape is loaded, the drive is online. In this state, the changer is unable to move a tape from the drive without first unloading the tape. However, if Auto-Offline is enabled, there is an implicit drive unload and so the tape can be moved from the drive even if an Unload command has not been issued by the application. This setting can be useful for certain applications, and is global across the VTL service (one setting for all drives).
ii.auto-eject: If a tape is moved from a drive or slot to a CAP it goes directly to the vault. This setting can be useful for those applications
that check to see that tapes have been removed from the CAP. They will fail their library "eject" operation if tapes are still in the CAP after a time delay. Auto-eject makes these applications happy because tapes disappear immediately from the CAPs. This setting also is global across the VTL service (one setting for all drives)
iii. It is best to utilize only one type of tape drive per library.
i. Consider spreading the backup load across multiple FC ports on the Data Domain system in order to avoid bottlenecks on a single port.
ii. Verify the speed of each FC port on the switch to confirm that the port is configured for the desired rate.
iii. Set secondary ports to "none" unless explicitly necessary for your particular configuration.
iv.Configure the host operating system driver for LUN persistent binding. Doing so avoids situations where, because of target changes, backup software or the operating system needs to be reconfigured. (From "Integrating the Data Domain System VTL with a Storage Area Network", page 8),
3. VTL Operation
Create sufficient slots to contain the number of tapes you have created. Creating a few extra slots is generally not a problem, as long as it is not an excessive quantity.
i. Create only as many tapes as needed to satisfy your backup requirements. Starting tape count is generally less than twice the disk space available on the Restorer. Creating too many virtual tapes can create a scenario where the Data Domain system can fill up prematurely and cause an unexpected system outage. As the global compression statistics become available, additional tapes can be added incrementally.
ii. If the system does reach 100% full you will need to delete any empty tapes that may exist on the system, then expire enough data to get the system below 80% capacity. In order to avoid this time-consuming task, it is important to prevent a system-full event from occurring.
iii. On a replication destination system, never read from a tape that is currently being replicated.
iv. Always use unique tape barcodes, even across different pools.
v. Always use the same tape suffix (size) across all pools. If for some reason you must use a different suffix, at a minimum you should keep the same suffix within a pool.
vi. Optimal size of tapes will depend on multiple factors, including the specific BA being used, and the characteristics of the data being backed-up. In general, it's better to use a larger number of smaller tapes than a smaller number of big tapes, in order to control disk usage and prevent system full conditions.
vii. For TSM, it is recommended to use smaller tapes (ie. 30-50G) in order to help reclaim space more quickly.
d. Back-up Applications
i. Ensure that you are using the largest optimal block size for your BA for maximum performance operating with the Data Domain system. Note that the optimal number will depend on many factors, such as disk speed, OS caching, as well as your specific backup software. Please see your vendor's recommendations, as well as the Integration Guides in the References section at the end of this
ii. In general, a tape block size that is a multiple of 64K will offer better performance, but be sure to check the Best Practices or Integration guides for your specific software (see below for links). If accessing the Data Domain device with multiple backup servers, use the largest block size accessible by all servers in the environment (especially in a heterogeneous OS environment).
iii. See Reference section below for links to Best Practices or Integration guides for your Backup Application.
4. Access Groups
a. Numbering of devices within each discrete VTL access group should begin with
b. It is best to avoid changing VTL access group configuration while the Data
Domain system is under heavy load.
c. It is recommended that you have exactly one initiator per access group.
a.When using the VTL filemark cache statistics, the reset of the statistics should bedone prior to tapes being loaded into the drives. If the reset of the statistics is performed after the tapes are loaded and accessed in the tape drives, the vtl show detailed-stats command may be misleading. The report may display the "free" counts to be greater than the "alloc" counts, which is unexpected but harmless in this case. This is caused by resetting the statistics of the drives while they are in use; the reset of the statistics is not an atomic operation.
b.As a general best practice, the statistics should be reset prior to tapes being loaded into the drives.
- Symantec NetBackup (NBU) Design Best Practices with Data Domain
- EMC Networker 7.6 Application Introduction
- Tivoli Storage Manager (TSM) Integration Guide
- IBM TSM Backup with EMC Data Domain Deduplication - BEST PRACTICES Planning
- Symantec NetBackup Integration Guide
- Symantec Backup Exec Integration Guide
- Oracle RMAN Best Practices with Data Domain
- Integrating the Data Domain System VTL ith a Storage Area Network