Mirroring with Virtual Tape

The simplest way to mirror data on tape between sites, is to define two sets of tapes drives, with one set working on channel extenders to a remote site. If the cable distance is 12km or less, then you can write to two tapes, one at each location, with very little performance impact. This is illustrated in the diagram below.

The problem with this approach is that it requires an application which can write to two output files at once. Most backup products (DFHSM, FDRABR) can do this, but few other applications can. This can be fixed by using extra job steps to copy the tapes, but this manual method is error prone. This method also misses out on the benefits of virtual tape.

Both these problems can be fixed, by setting a virtual tape system to duplex its output tapes. The application writes its tape data into a single virtual tape buffer, then the processing within the virtual tape system looks after the duplexing. This is illustrated below

The problem with this is that the application completes before both tape copies are written, so the copy is asynchronous. Does this matter? Suppose you are writing your payroll tape, and you get a disaster after the payroll job runs, but before the tape copy is made. You are mirroring your disks to a second computer site, so you bring all your systems up there, and all looks fine. You check out the payroll job, and it completed ok and it says the tape was written successfully. BUT, you have lost the 'virtual tape' data in the VTS buffer. No payroll tape, no salary. That is important to me. Another problem is that even if the copy tape did get written, without a virtual tape system at your second site, you can't read the tapes.

So the next best answer is to have two virtual tape systems, and mirror the data between the buffers.

This is better, but it is still asynchronous. This is implemented by IBM, in 'deferred copy' mode, and by SUN in a clustered configuration using immediate migration.

The next level of protection is to hold the application until the data is in both VTS buffers, by holding the tape rewind command

This is almost there, but it is not quite perfect. The application has to wait while all the data is written from the source cache to the remote cache. If the file contains a few gigabytes of data, this will take a while. If the job is critical, this delay might not be acceptable. This is implemented by a pair of IBM VTS systems in a PPRC configuration, running in 'immediate copy' mode.

The best way to mirror data, is to do it on a block by block basis. This means that the individual pieces of data are relatively small, and so they do not take long to send over a fibre channel. The problem with mirroring z/OS tape is that at the moment, there is no way to do this on a block by block basis. The only reliable way to get an indication that a data transfer is complete, is to trap the tape rewind command which occurs when all the data is written. For synchronous mirroring, when the source gets the tape rewind command, the operation is suspended while all the tape data is written out to the target Vtape cache. Once the data is safely stored in both caches, the operation can complete.

No-one does this yet, and as far as I know, it is not on anyone's road map.

back to top

Copyright © Lascon Storage Ltd. 2000 to present date. By entering and using this site, you accept the conditions and limitations of use