> > smaller tapes. And a backup that requires a dozen tapes
> > because they're only 10GB-sized incurs a significant time
> > penalty from all those media change times.
>
> ===
> Speaking only for my NetApp VTLs here, but the 'media change
> time' as in 'rewind, unload drive, put tape in slot, grab a
> new tape from slot, put in drive, mount/position' takes next
> to no time at all. Fractions of a second.
And speaking only for the setups I was testing, I saw five to well over
ten seconds, as measured in NetBackup's activity monitor. That was a
surprise; I didn't pursue it as I already wasn't thrilled at having 10
times more mediaIDs to deal with, tracking a hundred or more tapes for
one backup of a big server, ... No reason it wouldn't work that way;
_I_ didn't want it to work that way.
> > Good reason #2: backing the number of drives down produced
> > a need to multiplex [...] aggregate throughput
> > improved all the way up to mux 32.
>
> ===
> Multiplexing WILL work. In my ever so humble opinion, MPX was
> a band-aid to address the 'how to pipe data fast enough to
Never thought of it as a band-aid, personally. More of a way to spend
on good drives and not having to upgrade network segments and backup
clients that don't need the bandwidth for anything else but backup.
That, and a way to make DR faster when applied intelligently.
> fast tape drives' question. The VTL doesn't care. 1 MB/s or
> 100MB/s or anything in-between is fine.
Of course. The point was to get a lot of jobs in execution. 100
unmultiplexed drives or 10 drives with mux 10. Horses for courses and
all that.
> My main concern is that when doing restores off a multiplexed
> tape, the VTL READ speed off the disk(let's say it's 80MB/s)
> is the same whether there's MPX in the stream or not. The
> restore will throw away the bytes that doesn't belong to the
> client, so out of a 80 MB/s stream coming off the disk, you
> will throw away (let's say) 60MB and use only 20. It's this
> reduction in effective restore speed that's my main concern.
Perhaps you'll have time to test and share here? I'd expect NetBackup
to treat it as multiplexed tape and not read the intervening data. IME,
most multiplexed-tape-restore horror stories are no longer valid due to
a) fast-locate-block's ability to skip the intervening data (I have
never explicitly tested this), b) drives that supply data faster than
the client can write it and c) properly designed multiplexed backups can
restore multiple clients significantly faster than non-muxed (I have
tested b and c).
> > Good reason #3: the administrative overhead of, say, 128
> > drives versus 16 quickly became annoying. Pages and pages
> > of tpconfig listings going off the screen, or GUI device
> > monitor to look through... hard to see the drive situation
> > at a glance... process-troubleshooting... it slows
> > things up in real and (probably) imagined ways.
>
> ===
> While true, my experience is that virtual drives are quite
> reliable. There's no write errors or read errors detected by
> the media servers, and they don't have reasons to DOWN their
> drives. (That's somewhat of a simplification... if there are
> SAN hiccups, media servers may down all their drives immediately...)
> ===
Buses, HBAs, ports, fibre and switches are not my area of expertise, but
mis- and reconfiguration of these and some (to me) extreme distances
involved were given as reasons why I saw a non-zero number of drive
issues. More correctly, _didn't_ see them, as they were lost in the
weeds of many hundreds of virtual drives.
_______________________________________________
Veritas-bu maillist - Veritas-bu AT mailman.eng.auburn DOT edu
http://mailman.eng.auburn.edu/mailman/listinfo/veritas-bu
|
