ADSM-L

Re: anyone using ATA disk systems

2003-06-10 02:00:10
Subject: Re: anyone using ATA disk systems
From: Christo Heuer <christoh AT ABSA.CO DOT ZA>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 10 Jun 2003 08:01:43 +0200
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."

<Prev in Thread] Current Thread [Next in Thread>