All good advice. I would add a couple of points:
When checking performance on a VTL (especially deduped) be sure to check
both write and read speeds. Some VTLs will ingest very well, but when you
are running reclamation or large restores (especially multiples), you may be
limited by the re-hydration (recombobulation?) capabilities of the device.
In the same light, when you are running reclamation on deduped storage, the
same recombobulation must occur to feed the data back to TSM before it can
be re-written and deduped again. Since TSM controls the filepool dedup and
knows where all the blocks are, this process of rebuilding the data and
re-writing and re-de-duping is mostly done with pointers.
Bob.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Prather, Wanda
Sent: Wednesday, June 16, 2010 10:42 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Questions about vtl useage
"Pick Carefully" is indeed, the best advice.
If all you need is "additional storage", there are many configurations
of either VTL or disk/filepool that you can choose. Filepools are very
easy to manage in TSM. VTL's are more trouble to manage in some ways
(you'll likely be defining & managing dozens of paths), and there are
more parts that can break.
The 1 thing that would force you to choose a VTL, is a requirement for
LAN-FREE support, which can only be done to a tape or tape-emulating
device.
There are 2 things that would force you to choose filepool: either
wanting to run your TSM server as a VM (and I'm not saying that is a
good idea anyway), or wanting to use client-side dedup.
If none of those issues apply to your situation, there are lots of
combinations you can use. A VTL that dedups; a disk filepool with or
without TSM software deduplication: you can use disk of your own with a
VTL gateway that dedups; there are companies that will sell you a VTL
that dedups but behaves like plain disk so you can still use TSM with a
filepool for client-side dedup, and you can use a NAS device that dedups
but looks like plain disk to TSM so you can still use TSM with a
filepool.
SO, now that I"ve added to the confusion:
Here are the big MISTAKES I've seen people make over the last 4 years
buying VTLs (or some combination of the above stuff):
1) Buying a solution that only solves today's problem.
You need a solution that will solve your current problem, and will adapt
to the problem you will hit 2 years from now, whatever that is most
likely to be. For instance, if there is ANY likelihood that you would
face a big bump in storage requirements in 2 years, for heaven's sake
don't buy a VTL that can't expand to fit that need. Make sure you
understand how you would adapt what you plan to buy, in case of a)
needing more storage in the future, b) needing more throughput in the
future, c) adding to the number of TSM servers you plan to run in the
future, etc. There isn't really a good way to repurpose a VTL if you
outgrow it.
2) Not figuring out what your throughput requirements are. Some VTL's
are quite limited in throughput. Don't assume that because it's disk,
it will be fast. Figure out your throughput needs as well as your space
needs, and make the vendor configure to meet both requirements.
3) Not figuring on software or expansion costs.
Make sure you get bids for at LEAST 3 years of your support costs,
including the software costs. Also find out what it would cost if you
have to expand the puppy later by xx terabytes. Some of the VTL's are
licensed by TB, some are not.
4) Buying something you don't thoroughly understand.
VTL's are not magic. If you buy disk instead of a VTL, you have to deal
with spindles and buses and controllers and HBA's and firmware. If you
buy a VTL, you have to deal with spindles and buses and controllers and
HBA's and firmware at the back end, plus servers and HBA's and firmware
and software on the front end. If someone offers you a VTL, LOOK at the
hardware that makes it up. If someone offered you the same package as a
straight disk array, would you be happy to buy it? If not, why would
you want it as part of a VTL?
If after you consider all these issues you aren't comfortable that a VTL
is the right choice, or you just can't decide, buy disk. It's more
flexible and you can always reconfigure it, repurpose it, move things
around in your disk farm as you want. If you decide you need a VTL
later, you can add a VTL gateway in front of your own disk.
Wanda
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Huebner,Andy,FORT WORTH,IT
Sent: Monday, June 14, 2010 9:29 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] Questions about vtl useage
We currently use an older VTL for the primary pools and you might find
it hard to tell the difference between it and disks. With the deduping
VTLs out there the amount of storage needed will be reduced. Pick
carefully if you go the dedup route. There are major speed differences
depending on in-line vs. post processing.
Check the archives, there are plenty of threads on collocation and
cartridge size when using a VTL.
We are using 4 year old FalconStor VTLs with about 300TB stored. 2
crashes, no other trouble. We do use slightly undersized disk pools to
frontend the VTLs.
Andy Huebner
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Lee, Gary D.
Sent: Monday, June 14, 2010 7:55 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Questions about vtl useage
Tsm server v5.5.4 running on suse sles9 under zvm 5.3.
We are in need of expanding our storage. Currently have an ibm 8100.
The disk is cheap enough, but the licensing for additional storage is
outrageous.
We are thinking of switching to using a vtl for onsite storage and doing
away with our onsite tape.
Are any folks out there using vtl, and if so what kinds and what has
been your experience?
I currently have about 3 tB of onsite tape, looking to at least double
that when we pick up the exchange 2007 environment.
Thanks for any information.
Gary Lee
Senior System Programmer
Ball State University
phone: 765-285-1310
This e-mail (including any attachments) is confidential and may be
legally privileged. If you are not an intended recipient or an
authorized representative of an intended recipient, you are prohibited
from using, copying or distributing the information in this e-mail or
its attachments. If you have received this e-mail in error, please
notify the sender immediately by return e-mail and delete all copies of
this message and any attachments.
Thank you.
This electronic transmission and any documents accompanying this electronic
transmission contain confidential information belonging to the sender. This
information may be legally privileged. The information is intended only for
the use of the individual or entity named above. If you are not the intended
recipient, you are hereby notified that any disclosure, copying, distribution,
or the taking of any action in reliance on or regarding the contents of this
electronically transmitted information is strictly prohibited.
|
