|
Re: [Networker] Virtual Tape Library - saveset multiplexingslowsmigration
2007-01-25 10:36:38
We made the switch from Networker's Advanced File Type to the Virtual
Tape Library because of all the problems we had with the Advanced File Type.
Our biggest problems was the way Networker decided on which disk volume
in a particular pool it was going to write to. When transitioning from a
period of inactivity to a series of clients starting up via schedule,
Networker would always seem to pick on the disk volume that had the most
data on it, while other volumes in the same pool were near empty. It
requires a lot of hands on management for us to keep the Advanced File
Type working efficiently. Also, we found the automatic staging of data
when a disk volume reached the High-Water Mark did not work properly,
and caused huge problems with our nightly schedules.
We have 16 TB of disk dedicated to our disk to disk to tape environment.
With the Advanced File Type, we could keep 4 days of data on disk. By
simply switching to the VTL, we can keep 8 days of data on the same 16
TB. The key here is Networker works best thinking it is writing to tape,
and it always fills tapes before moving on to the next empty virtual tape.
Managing the disk is also very easy with the VTL, as compared to
managing a series of large filesystems configured for Advanced File Type.
I would certainly say we are very happy with the performance of our VTL
over the Advanced File Type.
Mark
Curtis Preston wrote:
You speak as if using disk as disk is somehow more advanced or better
than use disk as tape. I definitely wouldn't agree with that
generalization. I'd actually lean the opposite way if anything. Raw
disk has its place, but it has a number of limitations when compared to
VTLs:
1. More difficult to share between multiple storage nodes
2. Performance of a properly designed VTL will definitely outperform raw
disk, as it has a custom filesystem designed with backups in mind.
3. With rare exceptions (Data domain & netapp) all the cool stuff in the
disk backup market (de-dupe, replication, re-presentation of backups as
files, etc) is going on in the VTL market.
Since we're talking about NetWorker, though, I would say that NetWorker
automates movement of data from "real" disk better than it automates
movement of data from a VTL to a PTL. That is, unless you're good at
scripting.
---
W. Curtis Preston
Author of O'Reilly's Backup & Recovery and Using SANs and NAS
VP Data Protection
GlassHouse Technologies
-----Original Message-----
From: networker-bounces AT backupcentral DOT com
[mailto:networker-bounces AT backupcentral DOT com] On Behalf Of Steven Weller
Sent: Wednesday, January 24, 2007 8:21 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: Re: [Networker] Virtual Tape Library - saveset
multiplexingslowsmigration
Or it sounds like you may be ready to graduate to using real disk as
disk rather than emulating the limitations of tape. This would help you
really leverage (stream) those LTO resources.
-Steve
----- Original Message ----
From: Curtis Preston <cpreston AT GLASSHOUSE DOT COM>
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Sent: Wednesday, January 24, 2007 5:03:20 PM
Subject: Re: [Networker] Virtual Tape Library - saveset multiplexing
slowsmigration
The question is: why are you multiplexing to your VTL? Instead of
sending 40 jobs to 10 virtual tape drives, why not just create 40
virtual tape drives and turn off multiplexing?
---
W. Curtis Preston
Author of O'Reilly's Backup & Recovery and Using SANs and NAS
VP Data Protection
GlassHouse Technologies
-----Original Message-----
From: networker-bounces AT backupcentral DOT com
[mailto:networker-bounces AT backupcentral DOT com] On Behalf Of Mark Davis
Sent: Wednesday, January 24, 2007 1:47 PM
To: NETWORKER AT LISTSERV.TEMPLE DOT EDU
Subject: [Networker] Virtual Tape Library - saveset multiplexing
slowsmigration
Hello,
We have a FalconStor VTL in our backup environment. We use this as a
disk to
disk to tape configuration, where the client data is initially backed up
to
virtual tape, then after a few days we migrate/stage the data to "real
tape"
(LTO3) to free up disk space.
The problem we are having is the multiplexing of savesets on the virtual
tape. When we want to migrate a saveset from virtual tape to real tape
using
nsrstage, the throughput can be quite slow if the saveset was from a
slow
writing client mixed in with savesets from other much faster writing
clients
on the same virtual tape. It appears that the entire virtual tape is
read to
pick up the pieces of the saveset from the slow writing client.
Has anyone run into this? Any suggestions as to how we can improve the
performance when migrating our data off the virtual tapes to our LTO3
drives?
Thanks,
Mark Davis
University of Western Ontario
London, Ontario
Canada
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
|
|
|
