> > The idea is if you are using your VTL to produce not just random
> > storage, but map directly onto physical tape. If your local
> > compression
> > is greater than the drive's, then when you go to realize the virtual
> > tape onto physical storage, Nebackup may be tracking a single tape
> > (TAP001), but that data will not fit onto a physical device. Very
> > annoying. You now have to either get the application involved and
> > duplicate the data, or you have to track two pieces of
> > physical media as
> > a single unit and try to keep the application from knowing that....
> > Good luck with restores that don't involve the VTL.
>
> "[M]ap directly onto physical tape?" With my usual subtlety and
> understatement, let me say that this is absolutely insane. <insert
> smiley> A TAPE IS NOT A FIXED NUMBER OF BYTES/BLOCKS/SECTORS LONG.
Of course not. But I can assume with reasonable certainty that if 99%
of the advertised uncompressed capacity of a tape doesn't fit, it's a
problem with the tape that can be handled by swapping it out. And in
practice, I've never run into capacity issues with an uncompressed
volume like this.
If I attempt to use a greater amount though, I may run into an issue
that has nothing to do with a failing of a particular tape and cannot be
solved that way.
> This has nothing to do with compression; it has everything to do with
> the nature of the medium. Gaps vary, speed can vary, BOT/EOT (archaic)
> positions vary, tape backs up and erases a couple of inches of tape
> after r-a-w errors, ... Not only do different tapes hold different
> amounts of identical data, but the same tape will likely hold a
> different amount of data if you write the same data to it twice.
As an absolute, I agree with you. In practice, I've never found it to
be a significant issue.
> There is no way to guarantee that the contents of tape A fit onto tape
> B. Because of that, as I said earlier, no tape software ever made,
> AFAIK, makes such an assumption. If your method of using a VTL does
> make that assumption, that's between you and the VTL vendor--but I doubt
> you'll find support in NetBackup for that.
You got it. Nonetheless, it was very handy. The VTL can go in without
changing how the system works (it just assumes it's writing to tape),
and the tape can be realized after the fact and used without a VTL in
the future or at another location (something we did a lot). The
drawback was that we couldn't use drive compression. Instead we used
client-side compression. I was actually very skeptical that we could
use client-side compression effectively, but it worked pretty well for
the most part. We had a lot of beefy clients, so CPU didn't tend to be
an issue.
> > is greater than the drive's, then when you go to realize the virtual
> > tape onto physical storage,
>
> The way to realize virtual tape onto real (or virtual) tape is to do it
> the way all tape-to-tape is done: by software that understands tape.
> bpduplicate, for instance. It's trivial to dup a 1TB SDLT600 tape onto
> [a ton of] DAT4 cartridges.
If I were setting up the system today, I'd have no reservations about
using NBU for it all the way. When the VTL was put in, we had a lot of
concerns about how the management of the disk units would be done. The
hardware could be plopped in and not significantly change the existing
operation of the system. All told, it worked pretty well. Our problems
with it had nothing to do with the inability to realize uncompressed
tapes due to data not fitting.
> Perhaps I misunderstand what you're doing, but if you're using some VTL
> utility to do duplication, I don't believe you'll be happy. NetBackup
> won't know a darned thing about it, giving you a management problem for
> tracking, re-creating and restoring and raising TCO.
The VTL sees physical tapes in the physical library and creates virtual
tapes with the same "barcode". NBU writes to the virtual tapes. Later
they can be written to the physical tape. For a restore, there's no
confusion or change in how the volumes are tracked. NBU never needs to
understand that the duplication has occured because both volumes have
the same data and the same "barcode". I don't have to worry about
duplicate barcodes because only one of them is physically extant.
> If you use a VTL the way all I've seen are promoted--and the way it is
> tested before being supported by NetBackup, it is indistinguishable from
> a real library and drives and tapes; you should not have to change your
> operation at all.
For the setup I was using, it is indistinguishable (on the host side)
from a real library and drives and tapes. The difference is that on the
back end, it turns virtual tapes into physical tape from time to time.
For that purpose, it is useful to have all the data on a virtual volume
fit on a physical cartridge. As you mention, it may be impossible to
guarantee that as an absolute, but I don't remember a failure of that
type in practice.
> > (TAP001), but that data will not fit onto a physical device. Very
> > annoying. You now have to either get the application involved and
> > duplicate the data, or you have to track two pieces of
> > physical media as
> > a single unit and try to keep the application from knowing that....
> > Good luck with restores that don't involve the VTL.
>
> But it doesn't sound like it [using the VTL exactly as a tape library].
> Sounds like you're running a complex operation out of sight of
> NetBackup, which puts the burden on you to put things back together.
> Nothing wrong with that if you're up to it. Good luck.
>
> > would fit otherwise. I think now they do a better job of
> > emulating the
> > compression used by the drive and lopping off a bit so that you're
> > reasonably certain of the data fitting onto good media even with local
> > compression.
>
> >From your writing, you seem to be a person with experience. Isn't
> "kinda-sorta emulating some drive firmware, then fudging a bit, and
> hoping to be reasonably certain" an alternative spelling of "kludge?"
That's all I've ever expected a drive-side VTL (as opposed to app-side
disk managment like a DSU) to be. I'm assuming that tape and library
vendors aren't bending over backward helping someone else try to emulate
their product exactly.
I've certainly had problems with them, but they really have nothing to
do with the emulation stuff like that. It's the back end VTL database
and general hardware problems like other libraries.
--
Darren Dunham ddunham at taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >
|
