ADSM-L

Re: [ADSM-L] Need advice on a long term TSM storage solution

2007-10-26 12:47:24
Subject: Re: [ADSM-L] Need advice on a long term TSM storage solution
From: Ben Bullock <bbullock AT MICRON DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 26 Oct 2007 08:57:24 -0600
Just to agree with John. 
We find that we are upgrading tape technologies about ever 5 years, the
last jump was from 3590 to 3592 tapes. As he stated, TSM makes it very
easy to add the new devices and set up the hierarchy of the storage
pools to get it ready to go. Then some "move data" scripts to get the
process chugging along. It can take a while but it is very little
administration.

There is always the risk that when you read off of EVERY tape to write
to new media, you will find some un-readable data, (which is what you
always hear folks saying about tape), but in our case we read over 800TB
of data with over 700,000,000 objects and had 32 files comprising 5MB
that was unrecoverable (they were in a storagepool we do not put on a
copypool on purpose). I found that a very acceptable statistic.

Ben

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Schneider, John
Sent: Friday, October 26, 2007 8:29 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Need advice on a long term TSM storage solution

Nicholas,
        I think you are right to think about splitting your TSM instance
into two.  An 80GB TSM database isn't all that large, but if you
anticipate it growing gradually bigger from there and never levelling
off, it doesn't make any sense to wait.
        We recently had to split a TSM instance in two.  We started
planning it when the TSM database was 150GB (I know, already pretty big)
and we didn't get it done until the TSM database had grown to 225GB.
All the data in that growth was one LARGE client.  We have a single
client with 80TB (yes, TB) of disk.  So we had to split the client so it
has two TSM clients configured on it that send their data to two TSM
instances, splitting it by filesystem.  It was a big job and took a
couple months to use Export/Import node to migrate 40TB of the client's
data over to the new instance. 
        As for your question about the which media to use, I would
rethink your question.  I don't think you can find a media which is
guaranteed to still be readable in 7 or more years, and by then it might
be so expensive to maintain you would hate being tied to it.  Another
responder suggested something like DataDomain, and that might work for
the local copy, but most sites have an offsite requirement, and
DataDomain doesn't solve that problem.  (OK, some people are replicating
DataDomain to another disk array at a geographic distance away, but that
is not practical for people who use a 3rd party DR site, or one a
thousand miles away).  And if you went with a disk-based solution like
DataDomain, where would you be in 7 years?  Are most disk arrays at
their most reliable 7 years later?  You would have to come up with some
way to migrate to a new disk technology, too. DataDomain might give you
a path for that sort of migration; you would have to ask them.
        One advantage of TSM is that it is very flexible about it's use
of media.  If you are using LTO3, for example, and down the road you go
to LTO4, it is not that hard to use MOVE DATA to perform the migration.
If you have enough tape drives that you can set a couple of each media
type to continously run a string of MOVE DATAs, you might be surprised
at how painless it is.
        We are right now converting from 3592 drives in one library to
LTO4 drives in another library (both are IBM3584).  This environment has
7 TSM instances, 12 local storage pools, and 8 offsite pools.  We
started the migration a couple months ago, and have migrated about 700
tapes of 3592 data.  We have about 300 to go to finish the local data,
then we will start on the offsite data.  We hope to be be done by
February or March.  Yes, it takes a long time to move the data, but with
a couple simple scripts to run the MOVE DATAs, it doesn't take a lot of
people time to administer the process.  It just chugs along getting the
job done. 
        By the way, as a healthcare provider, we have HIPAA requirements
to save some of our tape data for the life of the patient, much longer
than 7 years.
        If you want me to share the scripts or more details offline,
don't hesitate to ask.

Best Regards,

John D. Schneider
Lead Systems Administrator - Storage
Sisters of Mercy Health Systems
Email:  John.Schneider AT Mercy DOT net


-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Nicholas Rodolfich
Sent: Thursday, October 25, 2007 5:08 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Need advice on a long term TSM storage solution


Hello All,

Thanks for your help!!

Our TSM server resides on an LPAR with 2 processing units and 12Gb of
RAM. We use an IBM 3584 library with an expansion cabinet and 16 drives
(8-LTO1 and 8-LTO2) We have 16 LTO3 drive on order to upgrade our
drives. Our database is at 80Gb so I think I am ready for a new
instance.

We have a HIPAA requirement to keep certain data for 3 years and other
data for 7 years.

What is the best storage solution for this type of requirement?

 I plan to manage the HIPAA data with multiple domains, management
classes, etc but I am not sure what storage medium to use. It seem no
matter which cartridge technology we use that it will end up being a
bunch of work over the years following the tape technology curve. Should
I be looking at something optical or electronic?

Additionally, does it make sense to incarnate another TSM instance?

Thanks for your patience and help!!

Nicholas



IMPORTANT NOTICE:  This message and any included attachments are from
East Jefferson General Hospital, and is intended only for the
addressee(s), and may include Protected Health (PHI) or other
confidential information.  If you are the intended recipient, you are
obligated to maintain it in a secure and confidential manner and
re-disclosure without additional consent or as permitted by law is
prohibited.   If you are not the intended recipient, use of this
information is strictly prohibited and may be unlawful.  Please promptly
reply to the sender by email and delete this message from your computer.
East Jefferson General Hospital greatly appreciates your cooperation.