Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
Page 1 of 8
V5R4 Virtual Tape on System i By Nancy Roper, IBM Americas Advanced Technical Support – System i
Article Abstract : "Virtual Tape was introduced to i5/OS starting at V5R4. Read on to
learn about the features and benefits of this function, along with hints and tips to use it to
your advantage"
About the Author: Nancy Roper is a Consulting IT Specialist. She currently works in the
IBM Americas Advanced Technical Support group, assisting the largest System i
customers with their availability strategies. Nancy is a seasoned technical expert on
System i tape, SAN, and BRMS, and is co-author of the redbook “iSeries in a Storage
Area Network” (SG24-6220).
As the pace of the world quickens, more and more companies need to keep their systems available
for as many hours as possible each day. Since backups typically account for a major portion of the
time that a system is not available, companies are very interested in tools and techniques to shorten
the backup window as much as possible.
At V5R4, a new function became available in i5/OS to assist in this task. Virtual Tape allows cus-
tomers to write their saves to virtual volumes that are stored on disk, and later duplicate these vol-
umes to physical tapes. For saves with large file data, and for companies who are using older tape
technology, this may offer a dramatic performance improvement, thus shortening the time when the
system is unavailable to the users. In addition, concurrent or parallel saves can be implemented us-
ing virtual tape, thus shortening the backup window without needing to purchase additional physical
drives.
If this function seems interesting to you, then read on! This article will explain how virtual tape
works, and describe the scenarios where this function can be helpful. It will also warn of situations
where virtual tape may not be the best fit. This article will then outline the planning steps required to
prepare for virtual tape, and list the steps required to implement it.
Benefits offered by Virtual Tape
Virtual tape provides the following potential benefits:
- Possible Backup Performance Increase
- Run Concurrent or Parallel Backups, without buying more drives
- Overcome Save File Restrictions
- Reduce Impact of Media Errors
- Reduce Impact of Tape Hardware Failures
- Backup Strategy for Quick Restores
Details regarding these advantages are as follow:
Possible Backup Performance Increase: Virtual tape saves typically run at speeds comparable to
save files when they are on a system with adequate resources. Depending on the type of physical
drive currently in use, this may provide a performance benefit, thus helping to shorten the backup
Page 2 of 8
window. For details, see the benchmarks in the Save/Restore chapter of the V5R4 Performance Ca-
pabilities Guide, which is available on the web at the following url:
http://www-03.ibm.com/servers/eserver/iseries/perfmgmt/resource.html
Run Concurrent or Parallel Backups, without buying more drives: One technique for reducing
the backup window is to run multiple drives simultaneously using concurrent or parallel backups.
With virtual tape, this can often be done without purchasing additional tape devices. i5/OS allows
up to 35 virtual tape devices to be varied on simultaneously. The saves can be sent to virtual de-
vices, and once complete, the users can return to their work. The virtual volumes can then be dupli-
cated to physical tapes as drives become available.
Overcome Save File Restrictions: Save files have been used for many years on the System i in or-
der to send saves to disk first, and later save them to tape. They offered good speed, but they had
several restrictions that are no longer an issue with virtual tape:
One Library per Save File: When using save files, a separate save file was needed for each li-
brary that was saved. For customers using Backup, Recovery and Media Services (BRMS), this
was not an issue because BRMS created the save files in the background. However, for custom-
ers who used native commands, the save files needed to be created and managed manually.
With virtual tape, an entire system save can be sent to a single virtual volume, thus avoiding this
situation.
Save-While-Active across Libraries: With save files, each library had to be saved with a separate
command in order for it to reside in a separate save file. This meant that save-while-active syn-
chronization could not span libraries when using save files. With virtual tape, multiple libraries
can be saved on a single command, thus allowing save-while-active checkpoints across libraries
Parallel Saves: Parallel saves could not be stored in save files. However, they CAN be saved to
virtual volumes. Note that the number of virtual drives should match the number of physical
drives that will be used for the duplication when parallel saves are used. This is required so the
parallel save “media definition” written to the tapes will be correct.
SAVSYS: SAVSYS system saves cannot be sent to save files. However, they CAN be sent to
virtual volumes. Note that the virtual volume needs to be duplicated to physical tape before it
can be used to perform a system recovery (D-IPL). The system cannot be IPL’d from a virtual
volume that is still stored on disk.
Larger Libraries can be saved: Save files had a maximum size of 1 TB. In order to save a bigger
library to save file, it had to be carved into multiple object saves. With virtual tape, this restric-
tion is removed.
Reduce Impact of Media Errors: As a customer’s tape inventory ages, they may begin to see occa-
sional media errors. These typically cause the saves to fail. It’s often difficult to get the saves re-
issued and completed within the maintenance window, particularly save-while-active saves that
would need to be restarted from the beginning in order to create the checkpoint again. Virtual tape
Page 3 of 8
uses disk as the underlying media which is typically protected from errors via RAID or mirroring
protection, so media errors are less likely to affect the backup. Errors that occur during duplication of
virtual media do not impact the production application, so are typically less of a concern.
Reduce Impact of Tape Hardware failures: With physical drives, the nightly backup window
would be affected if a drive was ever broken or unavailable. However with virtual tape, the backups
can still be run to virtual volumes as scheduled. The duplication to physical media can be delayed
until another physical drive is available.
Backup Strategy for Quick Restores: Some companies may devise a backup strategy whereby they
keep the virtual volumes on disk even after duplication. The physical tapes are moved to offsite stor-
age in case of a system or site loss. Meanwhile, adhoc restores can be performed quickly from the
virtual volumes. A similar strategy was available with save files, although it was cumbersome for
non-BRMS customers due to management of multiple generations of save files.
Scenarios where Virtual Tape may not be a Fit
There are some situations where virtual tape may not be the best choice of tools for a given backup
strategy. Two examples are as follow:
Misconception re Zero Downtime: There is a misconception that Virtual Tape somehow magically
allows backups to run with no downtime. This is not true. Virtual Tape provides very fast backup
speeds for customers with large file saves. Think of it as a very fast tape device. It would need to be
combined with other techniques such as save-while-active, external disk point-in-time-copy, or high
availability business partner solutions in order to shrink the backup outage to a small or negligible
timeframe.
Scenarios where Virtual Saves Don’t Offer any Performance Advantage: Sometimes virtual tape
will not provide any performance advantage. For example, consider a company that is currently us-
ing the latest tape device technology and has data that falls in the “user mix” category. The bench-
marks suggest that both their tape saves and their virtual tape saves will run in the 200-220 GB/hr
range. That means that the outage for the users would be approximately the same regardless of
which technology was used. However, with virtual tape, there would be an extra step to duplicate
the data to physical tapes afterwards. This would possibly put extra load on the system depending
how the disk was configured, and would also broaden the window of exposure when the data was not
yet safely on tape. Meanwhile, extra costs would have been incurred to buy the extra disk to hold the
virtual volumes. In this case, virtual tape may not have been the best choice, unless the company
was interested in some of the other benefits of virtual tape, eg multi-streaming of saves, avoiding
media errors, etc.
Technical Details regarding Virtual Tape
As mentioned above, i5/OS V5R4 introduced a software based virtual tape solution. It is included in
the operating system at no extra charge. It provides similar function to the hardware-based virtual
tape solutions that are offered on other platforms.
Page 4 of 8
Virtual tape is supported on every i5/OS save/restore command and API on System i, except for
SAVSTG.
There are a couple of places where virtual tape cannot be used:
• It cannot be used for installing i5/OS or Licensed Internal Code (LIC): these need to be in-
stalled via CD or from a physical tape containing a SAVSYS save.
• It cannot be used for tape operations initiated from System Service Tools (SST) or Dedicated
Service Tools (DST), such as a main storage dump or a dump to media: these need to run di-
rectly to a physical tape.
Virtual tape is compatible with all tape devices that are currently supported by i5/OS. When virtual
volumes are created, the density needs to be chosen to limit the block size to those acceptable for the
physical tape devices that the save will be duplicated to. The maximum block size allowed for a vir-
tual volume can be changed at any time by re-initializing the volume to a different density. Data
saved to a volume with density *VRT32K is compatible with all drives, but larger block sizes will
provide better performance, so companies are encouraged to use the largest block size supported on
their physical drives. The Virtual Tape redbook has an appendix showing the highest supported den-
sity and block size for each Tape device.
Virtual volumes are created as Integrated File System (IFS) stream files. They can be placed in the
system Auxiliary Storage Pool (ASP), in a user ASP, or in an independent ASP (IASP). User ASPs
and IASPs are highly recommended in order to avoid disk contention which could cause perform-
ance degradation. Disk i/o’s used for save/restore typically have a much larger block size than regu-
lar i/o’s, so when they are intermixed in one ASP, the production i/o’s may have to wait behind the
longer save/restore i/o’s, thus impacting performance on the production application.
Virtual volumes can range in size from 48 MB to 1 TB in size. There is great flexibility when dupli-
cating the virtual volumes to tape. If the virtual volumes are smaller than the physical tape, then
multiple volumes in the virtual set will be accumulated on the physical tape. If the opposite is true,
ie the virtual volume is bigger than the physical tape that it is being duplicated to, then the save can
roll to new physical volumes as needed.
When virtual volumes are created, the user has the option of asking to have the full amount of disk
space allocated and formatted up front, or having a tiny 4K space allocated, that will then be ex-
panded as the save is written. Save performance is considerably better if the space is pre-allocated,
but companies who want to minimize the disk space used by scratch volumes may choose to use the
smaller initial allocation. There is a command (WRKIMGCLGE, then select option 12 to Work with
Entries, then use option 2 to change the desired virtual volume) that will trim the virtual volume
down to the size of the data that is stored on it. This could be used if the user changed his mind after
pre-formatting all the virtual volumes, or if a tape expired, and a second smaller save was written to
it, so there was excess space formatted that could be released.
Virtual tape is implemented using the same techniques as virtual optical. An Image Catalog is cre-
ated which specifies the IFS directory where the virtual volumes will be created. People find it help-
ful to think of the Image Catalog as the virtual tape equivalent of the cartridge magazine on a 3590 or
Page 5 of 8
3570 or TS3100 (3581) Tape device, with a set of numbered slots. The virtual tape Image Catalog is
a giant cartridge magazine that can hold up to 256 virtual volumes. When a virtual tape operation
needs to run, the image catalog is mounted onto one of the virtual drives, and then the tapes inside it
are used for the tape function. Multiple Image Catalogs will be required if multiple virtual drives
will run simultaneously. When using BRMS, the image catalogs are mounted automatically, but
when running virtual tape via i5/OS commands, the user needs to mount the image catalog.
When issuing a save command, there are two parameters, compression and compaction, that may
need clarification. “Compression” indicates compression done at the system side. It was important
in the early days when staff was typically not available overnight to mount tapes, so maximizing the
data on each tape was important, even at the expense of performance. It is typically not used on cur-
rent tape devices due to the performance impact. “Compaction” indicates compression that is done
at the drive side. It is typically used on current tape devices and typically gives a 3:1 compaction ra-
tio, and corresponding performance increase on traditional System i libraries since 3 times as much
data is going to tape in each write. For virtual tape, compression is available, but not recommended
because it only uses low compression (approximately 1.5:1) and has a high performance overhead.
Compaction is not available when saving from disk to virtual volumes. However, when virtual vol-
umes are duplicated to physical tapes, compaction can be used to gain the usual benefits. Note that it
needs to be explicitly requested on the DUPTAP command via compaction *YES, not via compac-
tion *FROMFILE.
BRMS and Virtual Tape
Virtual Tape is supported by BRMS for most functions. Using BRMS is recommended since it helps
to keep track of the virtual volumes and their duplicates, and helps to manage the expiry and re-use
of the virtual media. In addition, BRMS automates some of the functions related to mounting image
catalogs.
Planning for Virtual Tape
Prior to implementing virtual tape, some planning is required. Here are the basic steps:
• ASPs for Virtual Volumes: Decide where to store the virtual volumes: the system ASP, a
user ASP, a standalone IASP, or a switchable IASP
• Disk Space: Decide how much new disk will be required to hold the virtual volumes. This
will depend on what data will be saved and whether it will be kept on disk for adhoc restores
after the duplicate tapes are made. Remember to include space for scratch virtual volumes
and recall that the data is not compressed when it is sent to virtual volumes. Allow a small
amount of extra disk (1-3%) for the various save information associated with the virtual vol-
umes.
• Virtual Volume Sizes: Decide what sizes of virtual volumes to create. Smaller volumes pro-
vide more flexibility since small saves can be written on a single tape, or larger saves can
span multiple tapes. One idea might be to make a series of smaller virtual volumes in one
Page 6 of 8
image catalog for smaller saves, and a series of larger volumes in another image catalog for
full saves. In BRMS these could be treated as different media classes as though they were
long/short tapes in the 3590 and 3592 world.
• Virtual Devices and Image Catalogs: Decide how many virtual drives and image catalogs
will be required, depending on the backup strategy.
• Performance: Consider the resources that will be required on the system to drive the virtual
saves: CPU capacity, memory, and disk arms. The Performance Capabilities Guide men-
tioned earlier in this article has some virtual tape benchmarks that may help. The CPU,
memory and disk arm benchmarks for physical tape devices may also be useful to provide a
starting range. Additional testing and benchmarking may be required as the virtual tape pro-
ject progresses.
• Saving the Virtual Volumes: decide whether to save the virtual volumes that are on disk
during a regular save of the system. If the IFS directory that contains the virtual volumes is
saved while the image catalog is in “ready” status, then the virtual volumes in that image
catalog are not saved. If the image catalog is in “not ready” status, then the virtual volumes
in it are saved. This could increase the save time dramatically. If desired, there are several
ways to control whether the virtual volumes on disk are saved when their directory is saved:
• Use the CHGATR command on the IFS directory where the virtual volumes are
stored, and mark them as “do not save”
• Use the LODIMGCLG command to mount the image catalog prior to running the
save, so the virtual volumes will be omitted
• When using the SAV command or BRMS equivalents, use the OMIT parameter to
specifically omit the directories that have the virtual volumes in them
Implementing Virtual Tape
In order to implement virtual tape, the following steps are required for both BRMS and non-BRMS
users:
• Install New Hardware: Purchase and install any new hardware required for the project, eg
CPU, memory, or disk
• Create any ASPs or IASPs required: Do the appropriate planning and setup for any new
user ASPs or IASPs that will be required.
• Create the Virtual Devices: this command needs to be done using the i5/OS CRTDEVTAP
command. It is not available via the iSeries Navigator panels.
• Create the Image Catalogs: this command can be done via the ISeries Navigator or via the
i5/OS CRTIMGCLG command.
Page 7 of 8
• Create the Virtual Volumes: this command can be done via the ISeries Navigator or via the
i5/OS ADDIMGCLGE command.
• Run a Test Virtual Save without BRMS: Vary on the virtual device. Load the image cata-
log into the virtual device using the LODIMGCLG command. Check the volumes in the im-
age catalog using the WRKIMGCLGE command and record the volume serial number of the
one to be used for the test save. Issue the SAVLIB command, indicating the virtual tape de-
vice and the virtual volume serial number. If desired, use DSPTAP to view the data on the
tape. Note that all of these commands can also be done using ISeries Navigator.
• Duplicate the Tape to Physical Media without BRMS: Use the DUPTAP command to
copy the virtual volume to a physical tape on the desired drive. Recall that the block size
must be compatible between the virtual volume and the physical tape. Remember to set the
Compaction parameter to *YES if compaction is desired at the drive.
For users who will be using BRMS, the following additional steps are required:
• Initialize the BRMS Devices: Use INZBRM OPTION(*DEVICE) to set up the BRMS De-
vice Descriptions for the virtual drives and the 4 default Media Classes, namely VRT32K,
VRT64K, VRT240K, and VRT256K.
• Create BRMS Locations: Create BRMS locations for the virtual volumes. It is usually help-
ful to have separate locations for virtual tapes and physical tapes. Some companies also
make a separate location for virtual tapes that have already been duplicated but are still avail-
able on the system, in order to keep these tapes separate from those awaiting duplication.
• Update the BRMS Device Descriptions: Update the BRMS Device Descriptions for the vir-
tual drives to use the locations created, and also set the other parameters required for your
backup strategy.
• Create BRMS Media Classes: Create any additional BRMS Media Classes required. Note
that the media classes to be marked as non-shared.
• Create BRMS Move Policies: Create any new BRMS Move Policies required, or update ex-
isting ones. If a separate location is being used to indicate virtual tapes that have already
been copied, then a move policy will be required to move the virtual tapes to that location,
and return them when they expire. A move policy will also likely be needed to send the du-
plicated physical tapes offsite.
• Create BRMS Media Policies: Create any new BRMS Media Policies required, or update
existing ones. The “Mark Tapes for Duplication” field is helpful for automating the process
of duplicating the virtual volumes to physical tapes.
• Create BRMS Control Groups: Create any new BRMS Control Groups required, or update
existing ones
Page 8 of 8
• Set up DUPMEDBRM Commands: Add any additional DUPMEDBRM commands to the
daily job streams to duplicate the virtual volumes to physical tapes. Confirm that the media
information is being saved following the duplication either via the DUPMEDBRM
SAVMEDINF parameter, or via the SAVMEDIBRM command
• Set Up Daily BRMS Maintenance: Review the STRMNTBRM and/or STREXPBRM com-
mands in the daily maintenance jobs to confirm they will clean up virtual tape media as de-
sired
• Test and Implement: Test the new backup strategy carefully, then add the new virtual tape
backups to the daily job streams
As always, once the new backup strategy is designed, plans should be made to run a recovery test to
ensure the strategy is sound, and staff are comfortable with the recovery procedures.
Summary
Virtual Tape provides new options for companies who are interested in shortening their backup win-
dow. It can provide faster backups due to improved performance and the ability to run concurrent
and parallel saves without purchasing extra physical tape devices. It can also reduce the impact of
media errors during the saves, or hardware problems on the physical tape devices. In addition, new
strategies can be devised where virtual volumes are used for adhoc onsite restores rather than recall-
ing duplicate tapes from offsite. Be sure to plan the implementation in advance, particularly the
hardware resources required for good performance. Use BRMS in order to manage the implementa-
tion well. Be sure to test the backup carefully prior to implementation, and plan a recovery test to
ensure the system can be recovered smoothly.
For more detailed information about the virtual tape function and step by step instructions to imple-
ment it, please see the redbook entitled “i5/OS V5R4 Virtual Tape” which is available at
www.redbooks.ibm.com. The publication number is SG24-7164.
Many thanks to Debbie Saugen, Joe Kochan, Christian Aasland, and David Bhaskaran for their assis-
tance in writing this article.