 |
Performance considerations |
|
|
| Do you know what factors are limiting the speed of your backup jobs? It wasn't that long ago that tape drives were almost universally considered 'slow' and disk was considered 'fast'. With the introduction of HP's Ultrium 460 tape drive, and especially the newest Ultrium 960 tape drive, this is no longer the case. In most cases, the tape drive can write data faster than the disk subsystem is able to provide data to it. Each environment is different, though; how can you help identify where your bottlenecks are? |
|
| HP has developed and made available for download (at http://www.hp.com/go/tape ) a free utility called HP Library and Tape Tools (often abbreviated L&TT). With it, you can test the speed of reads as well as writes from both disk and tape. L&TT will also help you keep tape drive and library firmware up-to-date and, should you ever experience a problem with an HP tape drive or library, it will generate a support ticket to help HP more quickly diagnose the issue. |
|
| If L&TT shows that the disk subsystem or server is the bottleneck, what can you do? Some possibilities include keeping the disk defragmented, performing an image rather than file system backup, organizing the file system in a "flatter" structure so that there are not so many levels of directories to traverse, optimizing your RAID stripe strategy, and moving the data in question to faster disk. |
|
| What if the disk subsystem or server is the bottleneck and the above solutions prove impractical or ineffective? Should you still consider a Virtual Library System? It's quite possibly. "Starving" a tape drive for data (when the feed is a slow disk subsystem, or data is coming over a slow feed, such as a congested LAN segment) results in what is called "shoe-shining" of the tape drive mechanism, where the tape is continually pulled back and forth over the tape head, resulting in excessive wear to both the tape media and drive mechanics. Performing the backup to a VLS instead of physical tape means that you are writing to disks, which are inherently a random-access media (tape is sequential), and which will not experience the problem of shoe-shining. |
|
| Once your data is off the production disk and on the VLS, it can typically be moved to physical tape much faster than it could have been from the original disk. Why is this? Because both HP's virtual library systems use file systems that are optimized for large block I/O, and because the original backup job took all your server's small, deeply nested files and put them into big blocks of data as a backup job. Now when it comes time to copy that backup job to physical tape, it can be accomplished with minimal overhead by the VLS. |
|
| In addition, don't forget that even if your backups happen at the same speed as they would have to physical tape, there are two inherent benefits to the HP virtual library systems. First, restores of individual files or an individual directory tree will tend to be much quicker and more reliable from VLS than directly from physical tape. |
|
| Second, the use of the VLS may enable you to perform your backups to tape much more efficiently, "time-shifting" them from the wee hours of the morning to normal business hours when IT staff is more available. The following chart assumes three backup jobs, A, B, and C, each of which takes 6 hours. The business is open from 8AM to 8PM, and backups can not happen during business hours. Therefore, the business currently uses three autoloaders to provide a physical tape copy of their business data. |
|
|
9PM - 3AM |
4AM - 8AM |
8AM - 8PM |
| Autoloader 1 |
Write Job A to AL1 |
Idle |
Idle |
| Autoloader 2 |
Write Job B to AL2 |
Idle |
Idle |
| Autoloader 3 |
Write Job C to AL3 |
Idle |
Idle |
|
|
|
9PM - 3AM |
7AM - 1PM |
2PM - 8PM |
| Action |
Write Job A to Autoloader 1
Write Job B to VLS
Write Job C to VLS |
Copy Job C from VLS to Autoloader 1 |
Copy Job C from VLS to Autoloader 1 |
|
|
| With the introduction of the VLS into their backup strategy, this company has gone from needing three autoloaders to needing only one, provided for incredibly fast single-file restore of data in jobs B and C, increased reliability of their backups by decreasing the need for physical tape cartridges and media management, and time-shifted most of their backup jobs to more normal working hours when IT support staff is on hand to correct any issues. |
|
VLS1000i |
|
|
| Most customers will attach VLS1000i to a Gigabit Ethernet switch (as opposed to directly connecting it to a single server). Most servers today come with two network ports. In this environment, consider putting the VLS1000i and one Ethernet port from each attached server on a dedicated subnet so that backup traffic does not clog the rest of your infrastructure. That is, if the subnet for the office is 192.168.10.xxx, configure the VLS1000i and one Ethernet port from each attached server at 192.168.20.xxx. |
|
| The VLS1000i is capable of sustaining two simultaneous backup jobs at up to 30MB/sec each, three simultaneous jobs at up to 23MB/sec each, or four simultaneous jobs up to 19MB/sec each. The best observed aggregate performance has been with two backup servers, each sending two simultaneous jobs to the VLS1000i (a total of four backup streams each going to a unique virtual device on the VLS1000i), where performance of approximately 20MB/sec/job was seen. |
|
Compression |
|
|
| Unlike physical tape drives, which have the ability to compress data seamlessly and quickly through dedicated hardware in the drive itself, virtual library systems including the HP VLS1000i and VLS 6000 family perform data compression in the software running on the VLS itself. Enabling compression on the VLS devices therefore will increase how much data the system can store, but also creates CPU overhead and limits the maximum performance of the VLS system. |
|
| This may not be an issue in the real world of your data center, however. For instance, two simultaneous streams on the VLS1000i with compression turned off can each stream at 30MB/second. If the data is 2:1 compressible and compression is turned on, performance may drop to the neighborhood of 11MB/sec for each stream. If the data sources are not capable of feeding data to the VLS 1000i faster than 10MB/sec (not uncommon for Windows server C: partitions, or drives with large numbers of small files), then whether compression is on or off will have no effect on overall VLS backup performance. In this example, though, enabling compression on the VLS1000i will enable it to store as much as twice the data as it would with compression disabled. Compression can be enabled or disabled per device. If you choose to run without VLS compression on some virtual drives, ensure that your backup software is configured to turn off both tape and OS compression for jobs using those devices. |
|
| Tip: How can you find out how fast your data sources can be read? Use the "system performance" feature of HP's free Library and Tape Tools, available for download from http://www.hp.com/go/tape. |
|
| Note: Most backup software also enables you to perform compression on the host (the server). Doing so will significantly increase the CPU utilization on your server and is not usually recommended as it may affect how responsive the server is to user processes. Also note that there is no benefit to having both server-side and backup device (physical or virtual tape) compression enabled; data once compressed can rarely be compressed further with the technology used in tape devices. |
|
| Tip: For most efficient use of physical tape when moving jobs from a virtual library to a physical tape device, use your backup software's object copy function. This will allow the full capacity of physical media to be used regardless of how compression is set on either virtual or physical tape drives. |
|
Printable version
