Veritas-bu

[Veritas-bu] Newbie to Netbackup using VTL

2007-05-14 13:48:00
Subject: [Veritas-bu] Newbie to Netbackup using VTL
From: kmeidal at amgen.com (Meidal, Knut)
Date: Mon, 14 May 2007 10:48:00 -0700
Warning, long ramble follows... I'll take the middle ground.

The existence of a VTL appliance is IMO due to the fact that backup
utilities (from now on limited to NBU) are not really stellar at using
"disk-as-disk" or DAD. They are reasonably good at using tape, as that has
been designed in from the very beginning.
Disk has unquestionable advantages (random access, near-zero mount/position
times), some more "it depends" traits, like transfer speed flexibility and
so on. 

Some of the downsides of using disk as disk are 

1) Concurrency to disk: if you have multiple media servers, how to ensure
they're cooperating peacefully when reading/writing to the same disk area.
You can do that in several ways:

        * Divide up in separate LUNs. Each media server owns it and creates
a file system on it. Very difficult to change the amount allocated to each.
Maybe a volume manager and advanced file system can address some of that.

        * Cluster file system. Good solution. Introduces complexity and
potentially cost. 

        * "Gentleman's agreement" sharing of LUN. Access to files are
centrally brokered by the master server. I believe this is how CommVault
Galaxy/GridStor operates. The servers asks broker politely before writing to
a certain disk area. Not a true cluster file system.

        * Use the disk as a network file system. Use CIFS/NFS to access your
disk pool and backup images. 

2) Provisioning/expansion of capacity. How to grow the LUNs, grow the
cluster file system, etc.

3) The backup application (especially NBU 5.1) IMO isn't very clever about
disk storage.


To get the best of both worlds, the advantages of disk, combined with NBU's
ability to administer tapes, the VTL was created, to use "disk-as-Tape".
NBU does the same ole thing it's always done, and reaps the benefits of
quick mounts and positioning, and the "hidden" capacity growth that happened
when adding more disk to the unit. (Just create more virtual tapes).
De-duplication can happen behind the scenes, NBU will never know.

The downside to VTLs are (or might be) that NBU does the backup to a tape
with a barcode. Job done! There is no insight into what goes on behind the
scenes, when the physical tape is removed etc. 

This is where Vault shines. It knows all about the primary copy, all the
secondary copies all the way thru the lifecycle. 
There is a layer of abstraction as to managing the VTL copy to the Physical
Tape, as well as potentially importing it again when restoring, we have
found that to be manageable.

I understand upcoming versions of NBU will have some integration with NetApp
VTL to handle some of these 'hidden' tasks. 

Additionally, the job of copying the disk data on to a physical tape takes
some amount of resources, from a CPU somewhere. If an intelligent VTL
doesn't do it, a media server will have to. If you have plenty of resources
on your media server, great, if not -you might affect the backup performance
while duplicating.

Bpduplicate in 5.1 appears to be inefficient. Upcoming versions couldn't
possibly be worse. (knock on wood)

As far as I know, there is no way of having a "duplication only" media
server role in NetBackup. The idea being that a client-facing media server
dumps data to a disk, then letting a NBU media server (not client facing)
read the disk data and write out to tape. This would offload the job from
the client-facing media server, and have NBU know all about the goings-on.
(A kind of roll-your-own duplication workload offload engine, or RYODWOE if
you will. (tm) )

So, bottom line:
VTLs are an intermediate way of using disk with your dumb backup
application. 
NBU isn't (yet) smart about using disk-as-disk. 
The VTL controller does a great job of offloading the media server to create
the phys tapes.
Redesign of application necessary to use disk optimally. Let's hope that
happens in 6.5 and onwards.

That was a long rant... I apologize, as I didn't have time to write a short
rant.

Knut Meidal


-----Original Message-----
From: veritas-bu-bounces at mailman.eng.auburn.edu
[mailto:veritas-bu-bounces at mailman.eng.auburn.edu] On Behalf Of Curtis
Preston
Sent: Sunday, May 13, 2007 10:58 PM
To: Liddle, Stuart; blaine_robison at yahoo.com;
VERITAS-BU at mailman.eng.auburn.edu
Subject: Re: [Veritas-bu] Newbie to Netbackup using VTL

Stuart Liddle said:
>NO....Don't use Vault to duplicate from VTL to physical tape!!!

Looks like it's my week to disagree with you, Stuart. 
(Sorry.  I love ya' man!)

>We tried this, and in NB 5.1 MP6, Vault is a HOG!!  We were not able to
>Keep the drives spinning fast enough using Vault.  The best speeds we
saw >going to physical tape using vault was maybe 30MB/sec.  Usually we
got 
>around 10MB/sec or less....which is definitely not a good thing.

I've been able to get Vault to go MUCH faster than that. I would say
there are keys to doing it right.  The biggest one I see is that you
should either use multiplexing or not.  Don't mpx to tape (or virtual
tape) and then de-mpx when you copy.  VTL will suck just as bad as
regular tape when you do that.  So either preserve mpx when you dupe, or
don't mpx to your VTL (better).  Another key is having enough I/O
bandwidth in the media server to pull it off.

>What we ended up doing was using the built-in feature of our NetApp VTL
to
>do the cloning of the virtual tape to physical tape.  Now we are
getting
>much better performance of around 50 - 60 MB/sec.

Glad it got better. ;)

>The problem is that Vault has way too much overhead in doing the
copying of
>the data.

Again, I have to disagree.

>With the built in cloning function of the VTL, you just connect the two
>firehoses together and the data gets written from virtual tape to
physical
>tape.

There are also limitations to this approach.  While it removes the I/O
from the media server, you get a lot of wasted media if you eject your
copies every day.  In addition, the backup software has no knowledge of
the copy process, so if it fails, you're on your own for monitoring it,
etc. (It's not that I don't recommend this approach, I just wanted to
say that it does have limitations, perhaps the chief of which is that
Symantec will disavow any support on any issues you have.  Yuck.)

---
W. Curtis Preston
Author of O'Reilly's Backup & Recovery and Using SANs and NAS
VP Data Protection
GlassHouse Technologies





_______________________________________________
Veritas-bu maillist  -  Veritas-bu at mailman.eng.auburn.edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu