|
Re: [Networker] Query in Staging from adv_file
2008-08-22 10:40:07
On Aug 22, 2008, at 3:29 AM, tkimball wrote:
[And Two Forum Pages Later...] ;)
Very interesting discussions. However, I have some direct comments/
questions for Curtis here:
-> How do you deal with sites like mine, who have 'DBO Option Tier
5' (aka Unlimited adv_file) and actually use it as our primary
storage? With VTLs now licensed by size, I don't see EMC (or in our
case Sun) 'trading in' one license for another while still keeping
us happy - do they have an equiv 'Unlimited VTL' license?
And its nice to be able to just 'drop in' disk for a project or a
specialized SN - its now just plain cheaper than looking at VTL for
the near future; Just buy a x4500 and a $2K SN license, or use an
existing x4100, $2K SN, and some older DAS disk (Sun 3000 series
SATA) using ZFS raidz2.
-> There's another factor that revolves around the above license
(and the VTL v. adv_file debate): Timing.
I implemented the adv_file solution in mid-2004. De-Dupe did not
exist. ZFS did not exist (and still doesn't, for what I need it to
do *sigh*). VTL did not (officially) exist. And, arguably, 'Big
Disk' as we initially implemented was not ready for prime-time
either (it finally worked in 2006 when the disk array was swapped
from PATA to SATA).
I'm curious if anyone else ended up in this situation. For that
matter, does anyone else here *have* a Tier 5 DBO?
Oh, and I personally can't be moved by 'bad VTL' stories so much,
when three words will make STK's entire support department cringe:
Fully Populated BladeStore [12 Trays]. I'm pretty skeptical of all
'big disk' equally, no matter how nicely you wrap it.
-> What is the point of de-dupe when more than half your data coming
in is pre-compressed, and is just likely to increase (especially
when pre-compressing gets you 2-5x more data per tape than the
average tape drive can do in real-time)?
That's a good question. Anyone who's considering deploying a dedupe
device has to try before buying, especially since there are two types
of dedupe to consider and each has its pros and cons. The benefit with
dedupe depends on the nature of the data. We are shopping for a large
intelligent disk target now (in the early stages) and this discussion
on VTL vs. adv_file is very timely. Until this discussion arose, I was
firmly in the adv_file camp, but now the VTL looks appealing. We are
looking at dedupe technology for our ERP solution which is due to
start coming into production this January with other modules going
into production over the next four years. Most of our ERP data is text
(e.g., names, course info, payroll info) and only a small portion of
it will consist of compressed image files (e.g., Documentum). As such,
in our situation, we not only expect to benefit by dedupe technology,
we expect not to meet our RTO without it. We recently issued an RFI to
various companies to send us estimated pricing and configuration info
on an intelligent disk target that includes the features that have
been discussed in this thread.
As far as a VTL, we actually have one in production here and a second
one sitting in a cabinet at Sungard. Our VTL is connected to our IBM
mainframe via ESCON for its exclusive use. Its a Bus-Tech device.
Satisfaction with that VTL is very high. It has been in production a
little less then a year. We rsync the Bus-Tech data over a private
network to Sungard, and soon to another site. Our Sungard DR exercises
on that data have been successful; we have another DR exercise coming
up soon. As an added measure of protection, we also back up our Bus-
Tech data to real LTO-3 tape via NetWorker. Those LTO-3 tapes are sent
off-site too. We went from shipping off a few dozen IBM tapes per day
down to seven one day a week (when we do a full backup) and three the
other days of the week. This has been a big cost savings for us, and
our mainframe programmers have supposedly not had to do much in order
to adapt to the Bus-Tech VTL.
It seems to me that both adv_file devices and VTLs have their pros and
cons. I have no regrets about nagging my management (and it did take a
lot of nagging) to get a Sun X4500 storage node. The pain point there
is the capacity is too low for our needs and I can't recover data when
staging is in progress, plus we can't grow the capacity of our X4500.
I am hoping the same level of satisfaction will occur if we deploy a
VTL for our backups that are controlled directly by 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
|
|
|
