Thanks very much, Curtis, for an excellent summary. It will be very helpful.
You touched on compression, but I still have questions. One vendor told us
that with most VTLs you can't use compression, because the VTL can't
compress identically the same as the drive will. You could end up with more
data on a virtual tape than will fit on the correspondnig physical tape and
therefore, in your words, "badness". The vendor's product, of course, worked
around this issue. How are real-world users addressing the situation?
Thanks again,
Conrad Macina
Pfizer, Inc.
On Wed, 22 Aug 2007 19:35:38 -0400, Curtis Preston <cpreston AT GLASSHOUSE DOT
COM>
wrote:
>I've read this whole thread now and wanted to comment on it with a
>little more thought...
>
>I in favor of VTLs or other intelligent disk targets (IDTs). It's not
>necessarily whether or not it's pretending to be tape; it's whether or
>not it deals with the issues of using "regular" disk, which are:
>
>1. Difficult to share between multiple storage nodes - must partition
>
>2. When partitioning for multiple SNs, you have to decide how big to
>make each slice.
>
>3. 1:1 relationship between size of backups and size of disk (i.e. no
>compression or de-dupe)
>
>4. Fragmentation: users have reported issues with using filesystems as
>targets for extended periods of time unless they're clearing the
>filesystem every night.
>
>IDTs remove with these issues:
>1. Easy to share - with a VTL, use DDS in NW or just make multiple VTLs.
>With a NAS IDT (Data Domain, NEC Hydrastor), just point a share at it.
>
>2. Do not have to partition by storage node or even NetWorker server.
>Whatever storage a SN uses, it uses.
>
>3. Some have hardware compression and others have de-dupe. I've seen
>it; it's real. And my opinion is that as long as you're also copying
>everything to tape, I've got no issues with using de-dupe at this stage.
>
>4. Fragmentation does not seem to be an issue as they use a MUCH larger
>block size that's better suited to backups. Fragmentation issues have
>also not been reported.
>
>Issues:
>
>1. There is the issue with managing migration to tape. With NetWorker,
>there are easy ways and hard ways.
>
>With disk/AFTD, you would use the disk staging facility in NW. It will
>automatically stage backups to tape from disk, and delete de-staged
>backups to make room for new babckups.
>
>With an integrated VTL (like the EMC CDL, IBM, Sun, Falconstor, NetApp,
>et al), you can have the CDL manage the migration. It sits between your
>networker server and the physical tape library (PTL). It inventories
>the PTL and represents to the NW server virtual tapes with the same
>barcode and capacity as the real tapes. You back up to the fake tapes
>and eject them. It then automatically copies them to physical tape.
>
>If you don't like either of these options, the "hard way" is to script
>your way into happiness. If you like this method, there's not much
>difference between an AFTD and a VTL/IDT from a migration perspective.
>
>2. There's also the issue where you can't expire a tape until all its
>backups expire. This is no different than physical tape. I think this
>is pretty easy to deal with. Either use really small virtual tapes or
>mark your tapes as full with a script after each night's backups. A 400
>GB tape marked full in a VTL won't take up 400 GB, so that's OK. That
>way, each night's backups are on their own set of tapes, causing all of
>them to be expired when those backups expire. (You also need to
>segregate by retention period if this is to work well -- just like with
>real tape.) You don't have this issue with an AFTD as it can expire
>individual savesets, but I think that an AFTD comes with too many other
>problems in large NW environments.
>
>3. If you use an integrated VTL, there is the issue of matching virtual
>to physical size. The big thing is that virtual tape MUST fit on the
>physical tape. Some VTLs allow you to pick the point at which the
>virtual tape is full. If you pick a size that's too big, you won't fit
>onto the physical tape and you've got badness. I like the new feature
>of "right sizing," where the VTL figures out when to stop by sampling
>the data that's coming through and seeing how well it's compressing.
>
>4. The license issue. As long as EMC makes it an option, it's not a new
>license they're trying to force down your throat. It's an optional
>license that allows you to configure your VTL any way you want (e.g.
>number of slots, etc.). As long as you stick with the "real" license,
>you're limited to what you paid for. Don't forget that AFTD costs
>money, too!
>
>I hope this helps.
>
>---
>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
|
