Please be aware that De-duplication is relative to your Rate of Change
(ROC), if your daily ROC is high, then your Dedup ratio's will uselessly
low and in most cases waste of money. Some VTL vendors state ratios such
as 18:1 and higher, but this is only if your ROC is around 5% and lower.
If your ROC was around 25% your not going to get any better than 5:1 Dedup
or lower which for the money invested could have been better spent on more
disk capacity.
please work out your ROC in your solution design to then be able to
identify the best path to take. Like all technology out there, its only
good in the right environment. if your happy with a 5:1 dedup due to a
high ROC, and have the storage capacity then by all means go for it, but
knowing this before going down that path is better than finding out
afterwards.
On Sun, 4 Nov 2007 23:23:51 -0500, Curtis Preston
<cpreston AT GLASSHOUSE DOT COM> wrote:
>Oscar makes some valid points about his concerns about VTLs. Some of
>them apply to all VTLs, some of them apply only to one or a few of them,
>and at least one doesn't apply to any VTLs of which I'm aware. The VTL
>industry has brought this FUD (fear uncertainty & doubt) upon
>themselves, as they often resort to FUD throwing to make the sale.
>Hopefully I can clear that up. (I don't work for any of these vendors,
>but I work WITH all of them.)
>
>As I'll say later in this email, I'm not sure VTLs DO add very much in
>small environments, or that they have a major advantage in backup
>environments that don't have multiple servers, but I do believe they add
>value in very large environments. I'll explain that later.
>
>First let me say that for any environment backing up multiple terabytes,
>I believe that using a non-dedupe disk device as your primary storage
>for backups is at this point a waste of money. Dedupe brings too much
>value to not use it in a disk target that's going to be used for
>anything other than staging. (Note: I'm not talking about disk staging
>here. I'm talking about using disk as your primary onsite storage
>device.)
>
>I'm assuming, then, you're going to be buying a dedupe device.
>
>>* VTLs can support data deduplication
>> - And so can raw disk with additional hardware.
>
>Today (and for the foreseeable future) there are only two types of
>dedupe devices: VTL and NAS heads. That means that if you want a block
>device that you can communicate to without using IP, then you're going
>to want VTL. If you're OK with IP/NAS-level performance, then either
>NAS or VTL can satisfy your performance requirements. Current data
>suggests that a dedupe VTL and dedupe NAS head add about the same cost
>to the disk, so then the question is: which brings more value?
>
>>However, data dedup loses
>>its appeal as it can't handle several save streams to one device at
>once.
>
>I think you're saying that dedupe devices can't support multiplexed
>backups and maintain their dedupe ratio. This is NOT true of all dedupe
>devices; it is true of some of them. (Ask your vendor.) In addition,
>I'd ask "why are you multiplexing to a disk device?" There's no reason
>to do that in a NetWorker environment. If you want to do 40 jobs
>simultaneously, create 40 virtual tape drives, not 10 virtual tape
>drives with 4 jobs each.
>
>>And why would I want to put an expensive and at the same time limiting
>>emulation layer between disks and software, as long as my software can
>>support disk-based backups?
>
>The biggest reason is de-dupe. (Other reasons come later in this
>email.) And the only way to get that today is to buy a NAS head with
>dedupe or a VTL head with dedupe, and the data I have shows that they're
>about the same price. If they're not, everything's negotiable.
>
>So then the question is: which works better for you? NAS or VTL? This
>one gets a little more difficult to discuss in this forum as it needs
>lots of drawings and such, but suffice it to say that I believe that the
>larger your environment is, the more you're going to want to LAN-free
>backups, and LAN-free backups can't be done to a NAS device (it's on the
>LAN).
>
>>* VTLs can help you cirrcumvent networker licensing for AFTDs.
>> - Considering both that VTLs impose severe limitations on what can be
>>done with disk, at an additional cost to that, this argument becomes
>>invalid. Besides, isn't EMC going to create specific VTL licenses too?
>
>While I don't agree that VTLs impose severe limitations, I do agree that
>this isn't a good reason to choose VTLs. The only limitation I'm aware
>of is the lack of simultaneous read/write, but I agree with another
>poster that said that this can be handled with proper configuration.
>(Basically smaller virtual tapes, but that does frustrate the licensing
>issue. I hope that NW comes out with VTL-friendly licensing soon.)
>
>>* VTLs can clone virtual tapes to physical ones, thus ofloading I/O
>from
>>the server.
>> - Buy a better server then? Besides, I assume that cloning of virtual
>>tapes to physical ones put a constratint on how much data can be
>squeezed
>>into physical media, as I assume its hard to calculate how much
>>compression can be done when the data is written to physical tape.
>
>I would totally agree with you here. FWIW, other backup products are
>working with some VTLs & NAS products to figure out how to do this
>without the drawbacks you mentioned. (Already GA in NetBackup.)
>
>>So, the conclusion is: Don't bother with VTL. Get a cheap JBOD, and use
>
>>ZFS, or a cheap RAID-capable box (InforTrend EonStor, Fujitsu-Siemens
>>Fibrecat SX88 or similar) and invest your money in a diskbackup license
>
>>instead.
>
>If all you want to do is disk staging, I agree with you for certain size
>environments. However, large environments are going to find a lot of
>value in dedupe and multi-head VTLs.
>
>>One other thing that's worth noting about diskbackup licenses for
>>networker is that the license puts restrictions on the actual amount of
>
>>data on disk, compared to library based licenses, who put restrictions
>on
>>the amount of slots instead. This means that unlike library licenses,
>>diskbackup licenses don't allow you to put more data in over time, as
>>technology evolves.
>
>That's an interesting thought. It's a drawback of capacity-based
>licensing.
>
>What value do _I_ think that VTLs bring to the table? In a small
>environment, I'm not sure they add much. (I don't think they subtract
>much either.) In medium-sized environments (one NW server, NO storage
>nodes), the addition of dedupe really gives you a reason to move off
>JBOD/RAID and onto an intelligent disk device. In such environments,
>most of the midrange dedupe NAS or VTL products will work. In large
>environments (multiple NW servers, storage nodes, perhaps other backup
>products as well), I'd say that VTLs win hands down over either standard
>disk or dedupe NAS.
>
>Standard disk is MUCH harder to use in large, multi-backup-server
>environments because of all the provisioning issues. You have to create
>and manage one or more RAID volumes per backup server/storage node, etc.
>You're always going to have volumes that are too big or too small,
>creating something else to manage. You can't easily move backups from
>one backup server/storage node to another. If you have different Oss,
>you can't even mount the RAID group/volume you made on OS to another
>OS's backup server. You get no dedupe or hardware compression. You
>will have fragmentation issues if you use them as a permanent storage
>device (as opposed to disk staging.)
>
>NAS disk (dedupe or otherwise) doesn't meet the needs of very large
>environments either, as many of the servers that need to be backed up
>need LAN-free backups. LAN-free backups mean using a block device, and
>today a block device means either standard disk or dedupe VTL. I've
>already said what I thought about standard disk, so that leaves only
>VTL.
>
>VTLs can easily be shared between multiple backup servers, storage nodes
>-- even applications that don't share -- without creating and managing
>individual RAID volumes for each server. They have dedupe and hardware
>compression, and any good dedupe device has worked out the fragmentation
>issue as well.
>
>---
>W. Curtis Preston
>Backup Blog @ www.backupcentral.com
>VP Data Protection, GlassHouse Technologies
>
>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
|
