Brendan,
Thanks for sharing you experiences with VTL. I know there will
be some polarisation with pro VTL and pro Adv-disk so I thought I'd
share an experience from the other camp :)
We use Adv-disk and have done since they were first introduced (and
plain disk devices before that). We started with locally attached disk
for backing up slow remote devices that were hogging tape drives then
moved up to 10TB for Networker use and, about 12 months after that, a
storage node with another 20TB. That kept us ticking over for years.
We've just added a further storage node and another 20TB. Other parts of
our organisation are going down the VTL route but, even with your stated
advantages, it doesn't seem to offer the same flexibility that I have
with adv-disk.
We use 2TB vols and have the cloning and staging scripted (Networker
doesn't seem to good at doing these things itself - autocloning delays
end of group until cloning finished, autostaging is a bit clunky too,
etc.). We backup to disk over night, clone to tape early morning ready
for offsite then stage disk to tape after a week or so. Whole setup
works very well. We've even done away with the need to share drives,
each storage node has dedicated drives to which the storage nodes can
send data as fast as the drives will take it (we don't have machines
that are capable of streaming more than 2 or 3 LTO3s at the same time).
We shift around 170TB per month.
We heard of one issue with a VTL where something happened (not sure what
it was, panic or some other glitch) the VTL reset itself and promptly
forgot about all of its volumes and zeroed everything that wasn't a
physical tape. Some glum faces over that...
Also, there's the issue of where the data is, is it in the library on
disk, in the library on tape? How would Networker know? It just has it
as being in the library, the VTL keeps a separate catalogue of what's
where.
I do like the idea of offloading the processing from Networker but I
think that is easily achievable by using storage nodes. One area where
VTL scores over our current setup is the ability to replicate VTL to
VTL. (We may come up with something that allows us to replicate adv-disk
- maybe clone to another adv-disk at a remote location or something, but
we don't have that capability right now).
To summarise, then, I'm a fan of adv-disk devices and, while I think VTL
technology has come on leaps and bounds, I think there's still a good
way to go before I'd feel happy going that route.
Regards
Bob
>-----Original Message-----
>From: EMC NetWorker discussion
>[mailto:NETWORKER AT LISTSERV.TEMPLE DOT EDU] On Behalf Of Brendan Sandes
>Sent: 03 May 2007 08:25
>To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
>Subject: Re: [Networker] SUN X4500 'Thumper' as a storage node?
>
>Thought I'd throw my 2 cents in with regard to VTL. My
>primary experience is with EMC disk libraries (formally CDL)
>
>I used to think the same way as Oscar - i.e. why bother with a
>VTL when you can just use disk.
>
>In a single networker server instance (or probably even one
>storage node), or a small requirements e.g. up to a terrabyte
>or two I probably wouldn't use a VTL. However, once you start
>getting storage nodes into the mix, they start to come into
>their own. Consider the following 1. you can create as many
>virtual tape drives as you want 2. with backup to disk, you
>have to allocate this to a given storage node.
>In a VTL, this one big pool of disk is carved up into X size
>chunks that match a tape format. This disk is then availabel
>to ANY storage node that you have allocated a virtual drive to
>(no need to script unmounting and remounting filesystems
>between storage nodes) 3. your physical library for long term
>storage can be connected directly to the storage node reducing
>load produced by cloning (Depending on make and
>model) from both the server (cpu & IO) and network (bandwidth).
>4. While the saveset is in the VTL you are still restoring
>from Disk (NetWorker takes care of media management as usual)
>5. If you add more storage nodes, you simply configure the
>disk library to create another couple of virtual tape drives
>which share the same pool of virtual tapes. This avoids the
>problem of tape drive contention that you get with say 4
>drives and 8 storage nodes.
>
>The disadvantages as I see them are
>1. As oscar said, you can only do one read/write to a virtual
>tape at a time. If the tape is in use, and you need to
>restore, you've just gotta wait.
>2. The main limitation when using with NetWorker comes mainly
>when you are wanting to keep browse policy equal to retention
>policy and you have to clone data off to reclaim space in the
>VTL. This is currently a scripted solution.
>
>Cheers!
>Brendan
>
>On 4/24/07, Oscar Olsson <spam1 AT qbranch DOT se> wrote:
>>
>> On 2007-04-23 14:15, Stan Horwitz revealed:
>>
>> SH> We don't currently do any kind of disk-to-disk-to-anything
>> SH> backups. I
>> do not
>>
>> Ive been following this thread for a while now. What I can't figure
>> out is why one would want to stage from disk to disk when it
>comes to backups?
>> Why not write to the secondary disk storage (i.e. cheap
>disk) right away?
>> There are several cheap storage systems (for instance the
>systems from
>> http://www.infortrend.com) where they just supply a disk
>array, where
>> you then buy off-the-shelf products such as actual disks and
>> controller RAM yourself. In terms of I/O performance, even these
>> systems should be more than enough for backups. So why do people use
>> tiered disk for backups, or VTLs? To me, the point of VTL is just to
>> work around backup products that aren't good at working with file
>> systems or block devices as targets of backup data. VTLs
>just seem to
>> limit the functionality of the actual disk, by emulating library
>> behavior, with its set of limitations such as random
>paralell I/O. Why
>> not just use adv_file devices instead, and then just stage
>that data to tape?
>>
>> //Oscar
>>
>> 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
>
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
|
