Excellent discussions.
I'd like to add that a lot of the benefits to implementing a VTL
solution are difficult to quantify. Eliminating off hours tape problems
is a huge ROI, but it is difficult to show that in justifying cost.
Another huge benefit in our shop is with oracle archive backups. If you
are depending on tape for that, and you have a library problem that
takes the whole library away, you could be in big trouble if you haven't
sized your archive targets to give you the window you need to fix the
hardware. VTL takes that concern away.
So many advantages, and you all have covered most of them. Decreased
backup and restore times, more streaming abilities, no physical tape to
deal with, etc...
My off hours calls have literally gone to zero since implementing VTL.
It also allows you to still leverage what tape investment you have
through cloning, because more times than not the alternative to cloning
through replication requires a pipe size that most companies cannot
afford. This is one reason I like VTL over NAS AFTDs. This then creates
potential for doing more cloning in the same window, because you have
more "tape" resources. The other is being able to get fibre speeds on
VTL tape. When Ethernet 10 Gb becomes more mainstream, then the fibre
will become less of a compelling factor.
I think that adding dedup is the tricky part, because that in almost all
cases requires extensive analysis and redesign of the backup
infrastructure to make sure the performance limits of your dedup
appliance are not exceeded. The part I don't like about that is that
this is not usually obvious, depending on the vendor you are working
with. This is where the backup product flexibility and structure may or
may not lead to an easy supportable solution.
I think most of the backup products are coming up to speed on being able
to take better advantage of dedup, and if not, they will if they want a
future with dedup solutions. Conversely, the VTL and dedup solutions are
getting better at handling those inherent bottlenecks of an existing
backup infrastructure.
VTL is the single greatest addition implemented in our backup space, for
the single reason of eliminating the headache of supporting physical
tape and hardware.
And, no off the cuff NW remarks. VTL will help any backup product, and
it is the bigger shops that it becomes extremely attractive.
I am familiar with the Diligent and EDL product lines. Both work
superbly, when implemented correctly.
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On
Behalf Of Curtis Preston
Sent: Thursday, August 21, 2008 4:11 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Query in Staging from adv_file
Oooh. This is fun. Let's not change the thread, as I'd like to keep
the discussion going all in one thread.
Wilbur Aymond said:
>VTL: Why?
It gives you the benefits of tape without the drawbacks.
Most of my arguments have to do with large environments. In smaller
environments, I'd go either way. But as soon as you get to multiple
storage nodes, my arguments come into play.
* It's easier to share a VTL among multiple storage nodes
* It's even easy to share one between multiple backup apps!
* Provisioning is a lot easier than with disk.
(Typically, no LUNS or filesystems to manage or grow)
* Your backups would actually work (that's also true of AFTD)
>Best reason for *not* using a VTL: Cost.
Not anymore.
> Unless things have changed drastically in the past few years,
They have.
>VTLs are and always will be much more expensive than a tape library
Most of them (if using dedupe) are now as cheap, if not cheaper than an
equivalent tape library. It's what is finally causing a massive surge
in purchasing them.
>but one of the most expensive components remains the same for far
longer
>than you will *ever* see a VTL last. Depending on the type of disk,
>I believe these are rated to 3-5 years, for 24 hour operation of
>non fibre disks.
Are you seriously comparing the long term viability of a tape library
over a VTL? Yes, disk fails, but so do tape drives. And they get
replaced, just like with tape drives. And, while tape libraries may
last longer than 3-5 years, very few people keep them that long.
>Assuming you sized things correctly, in a few years time, your VTL will
be >outgrown by either capacity or bandwidth. Will you be able to
upgrade it?
Yes you will if you bought the right one.
>No. Like any disk system, eventually forklift replacement is your only
>option.
The ones I look at are actually more scalable than most tape libraries I
know. Some of them have infinite ability to expand both capacity and
throughput.
>This doesn't even begin to address the costs of training,
documentation, >etc. involved.
No more or less than a tape library. In fact, I'd say it's less.
>This also doesn't even consider the fact that in most cases, you won't
be >getting rid of your tape library entirely, you'll just be adding
another >component to your infrastructure.
Most people are doing one of the following:
1. Buying disk instead of another tape library or growing the one they
have
2. If they're going to throw away their current tape library, then they
Replace it with one that's significantly smaller.
> -Which as we all know more components can mean more potential problems
and > more expense
Yes, but by making disk your primary target, a significant number of
your problems go away, and it's much easier to keep the tape drives
happy if they're being streamed by copying data from a VTL.
>as you cannot do long term backup storage on a VTL without
>breaking your wallet. (yes DataDomain and others have some good dedup
>products, but this is still not an offline, long term (1+ year)
solution)
>for most cases.
Yes you can. I'm not sure I'd do 5+ years on a VTL, but 1-3, sure.
And, believe it or not, the longer you store stuff in a dedupe VTL the
cheaper it gets per MB. That isn't true for tape.
As to dedupe, you mention it almost as an aside. Dude, it's the mutt's
nuts. There's a reason it's the most hyped technology since VMware. It
works and really does give you the benefits of disk without the cost
element you seem to be so worried about.
>why use a VTL for this? There's a much better solution.. Disk.
I will agree with you for small shops, not for big shops. Another
reason is that if you want dedupe (and you want dedupe), then your
choice is VTL or NAS (not LUN/filesystem access, but NFS/CIFS). If
you're a big shop, you want to send your stuff over Fibre Channel, not
IP. If you want to do that today and get dedupe, then you go VTL.
>And I'm not talking AFTD (which based on the discussions I've been
reading >through here "advanced" file type device is a bad joke to say
the least). >I'm talking *snapshots* and *replication* to disk. There
are plenty of >different brands of this, host based, network based,
filer based, etc. So >what do you get here? The same things you get with
a VTL, only better, and >cheaper.
Why didn't you say so in the first place? NO argument there, but that's
a much bigger discussion. I actually prefer snapshot and replication
(which I call near-CDP) to any of this stuff, but the whole world's not
ready for it yet.
Most changes in backup environments are made in small steps, and what
you're describing is just too big of a step for most people -- although
I'd be happy to help someone make that conversion.
Also, I have priced your idea vs a dedupe VTL in customer environments.
Without giving away the vendors, I will say that in the last customer,
the cost actually came out the same. (Snapshots/replication vs backup
to a deduped VTL.)
-----Original Message-----
From: EMC NetWorker discussion [mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU]On
Behalf Of Curtis Preston
Sent: Thursday, August 21, 2008 2:04 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Query in Staging from adv_file
>I don't think device count is relevant in a NetWorker environment
>because EMC doesn't license anything based on device count.
That's not entirely true. First, there are versions of NetWorker where
you're only allowed to have a certain number of devices (e.g. 4 tape
drives). Second, there is Network Edition and Power Edition, where the
number of concurrently used devices is regulated.
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. This message contains confidential information and is
intended only for the individual named. If you are not the named
addressee you should not disseminate, distribute or copy this e-mail.
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
To sign off this list, send email to listserv AT listserv.temple DOT edu and
type "signoff networker" in the body of the email. Please write to
networker-request AT listserv.temple DOT edu if you have any problems with this
list. You can access the archives at
http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
