Hi John,
There is currently an alternative to bypass the limitation/issues
Andrew brought up...
A company with the name of Dilligent software uses a prodcuct called
copycross which has a good approach to the problems with a very
large disk pool in TSM as a replacement for tape:
They basically simulate a DLT tape library with a Linux server - then you
just define the library to TSM - and send your data to it.
This solution will then write the data to Virtual drives/tapes - plus
you can define as many virtual drives as you require. The only issue
is the fact that it currently only works with EMC Symmetrix/Clariion disk
subsystems, but what makes it good is the fact that you can make use of
the replication facilities/srdf of the EMC boxes. So, you end up either
using
TSM's tape copy functionality for DR or you just let the EMC box mirror the
virtual tape data to another site...
This solution keeps the tapeness of the data without the drawbacks of
tape. Slow/unreliable etc....
Cheers
Christo
--------------------------------------------------------------------------
Mr. Raibeck,
I appreciate your feedback and, being involved in IT for some 30 years, I
understand the technical challenges involved. That is why I posted the
question. With the falling cost of disk architecture, a disk to disk backup
alternative seems to be coming close to rivaling disk to tape as a backup
alternative. Especially when dealing with some of the more sophisticated
tape solutions that involve the mainframe/zArchitecture.
If I size my TSM solution such that I can recover 'x' number of
application servers in a given number of hours, then I will require a
certain number of tape drives based on the data transfer rate of each tape
drive. Hence, any recovery process in DR mode is limited to the number of
tape drives available. Ouch!!! With disk to disk, my limitation is the TSM
server and the network.
Add to the mix the fact that tape data transfer speeds are less than SCSI
and/or ATA data transfer speeds and the thought is that with capacity of
disk architectures increasing rapidly and the price currently lower than
tape, it makes sense to back up everything to disk!!! Faster and lower cost!
So, I/we would appreciate IBM Tivoli's support of this concept.
With all the pressure on budgets and all these jobs NAFTAing, I MUST
arrive at the best solution! Thanks for your consideration.
John G. Talafous IS Technical Principal
The Timken Company Global Software Support
P.O. Box 6927 Data Management
1835 Dueber Ave. S.W. Phone: (330)-471-3390
Canton, Ohio USA 44706-0927 Fax : (330)-471-4034
talafous AT timken DOT com http://www.timken.com
-----Original Message-----
From: Andrew Raibeck [mailto:storman AT US.IBM DOT COM]
Sent: Monday, June 09, 2003 1:33 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: anyone using ATA disk systems
Addendum: I as I said earlier, we continue to study the matter. Possible
outcomes include enhancements that will enable TSM to function better in
an all disk storage pool environment, although we make no commitments at
this time.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Andrew Raibeck/Tucson/IBM@IBMUS
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
06/09/2003 10:25
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: anyone using ATA disk systems
We have not done a lot of testing on this, so this can not be taken as a
definitive statement. With that said, the following sums up our current
thoughts on this:
- Because there is no reclamation for random access storage pools, (a)
disk fragmentation is definitely a concern, and (b) aggregates are not
rebuilt, so as objects within an aggregate expire, that space is not freed
up until all objects in the aggregate have expired. This can cause
inefficient utilization of the disk space over time.
- FILE device classes could be used, but represent configuration and
performance concerns.
- While such an environment is technically possible, it is not the
intended TSM usage model, and we do not recommend it at this time.
- We continue to study this issue.
Regards,
Andy
Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.ibm DOT com
The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.
Steve Schaub <Steve.Schaub AT HAWORTH DOT COM>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
05/23/2003 07:08
Please respond to "ADSM: Dist Stor Manager"
To: ADSM-L AT VM.MARIST DOT EDU
cc:
Subject: Re: anyone using ATA disk systems
Hey Andy R, how about getting some Tivoli developers on the server-side
to throw some answers at this. I have spoken with many users, business
partners, & architects and have yet to get a consistant picture. Some
insist that using one huge diskpool works fine, others say the disk
format leads to disastrous fragmentation and the only way to go is file
class volumes, still others say not to even try this approach. Maybe a
Tivoli white paper specifically addressing disk-only primary storage
pools would give a definitive answer?
-----Original Message-----
From: Talafous, John G. [mailto:Talafous AT TIMKEN DOT COM]
Sent: Friday, May 23, 2003 9:26 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: anyone using ATA disk systems
We too are considering a mass expansion of our storage pools to
implement Disk to Disk backup via TSM. The reason is to enhance recovery
times. The Nexsan ATABeast is under consideration. We currently have
about 40TB backed up to TSM storage pools. I am thinking of bringing in
MANY TB of ATABeast so that we can discontinue migration to tape. I am
curious as to what happens internally in TSM when you drive your storage
pool utilization to, say, 80% and hold it there? Are there any
performance penalties? Any cautions? Any real world experience? How
much ATA should I consider?
TIA,
John G. Talafous IS Technical Principal
The Timken Company Global Software Support
P.O. Box 6927 Data Management
1835 Dueber Ave. S.W. Phone: (330)-471-3390
Canton, Ohio USA 44706-0927 Fax : (330)-471-4034
talafous AT timken DOT com http://www.timken.com
**********************************************************************
This message and any attachments are intended for the individual or
entity named above. If you are not the intended recipient, please do not
forward, copy, print, use or disclose this communication to others; also
please notify the sender by replying to this message, and then delete it
from your system.
The Timken Company
**********************************************************************
______________________________________________
"The information contained in this communication is confidential and may be
legally privileged. It
is intended solely for the use of the individual or entity to whom it is
addressed and others autho
rised to receive it. If you are not the intended recipient you are hereby
notified that any disclos
ure, copying, distribution or taking action in reliance of the contents of this
information is stri
ctly prohibited and may be unlawful. Absa Bank Limited (registration number
:1986/004794/06) is lia
ble neither for the proper, complete transmission of the information contained
in this communicatio
n, nor for any delay in its receipt, nor for the assurance that it is
virus-free."
|