ADSM-L

Re: SUSPECT: (MSW) review of recent addition of sata array storage pool

2005-03-14 10:59:35
Subject: Re: SUSPECT: (MSW) review of recent addition of sata array storage pool
From: PAC Brion Arnaud <Arnaud.Brion AT PANALPINA DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 14 Mar 2005 16:59:00 +0100
Steve,

I agree with you : collocation on this kind of storage pool doesn't seem
to make much sense. 
However I've read something in IBM's Administrator guide for 5.2 (ref
GC32-0768-01), page 206~207, that made me doubt. It states :

"If you decide to migrate data from one sequential access storage pool
to another,
ensure that:

- Collocation is set the same in both storage pools. For example, if
collocation is
set to yes in the first storage pool, then collocation should be set to
yes in the
next storage pool."

As I saw you where migrating data to a collocated tape-based pool, I was
curious !
Cheers.


Arnaud 

************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone:  +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Steve Bennett
Sent: Monday, 14 March, 2005 16:34
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: SUSPECT: (MSW) review of recent addition of sata array
storage pool

I did not collocate the sata diskpool. I believe that collocation would
restict the use of multi process restores, might cause more disk
partition fragmentation and I really did not see any benefit.

PAC Brion Arnaud wrote:
> Hi Steve,
>
> Just wanted to ask if your sata disk pool was collocated. We will soon

> implement the same kind of setup, and I'm still wondering if 
> collocation using sequential type disks makes sense ...
> Cheers.
>
> Arnaud
>
> **********************************************************************
> **
> ******
> Panalpina Management Ltd., Basle, Switzerland, CIT Department 
> Viadukstrasse 42, P.O. Box 4002 Basel/CH
> Phone:  +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
> Direct: +41 (61) 226 19 78
> e-mail: arnaud.brion AT panalpina DOT com
> **********************************************************************
> **
> ******
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of Steve Bennett
> Sent: Friday, 11 March, 2005 23:51
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: SUSPECT: (MSW) review of recent addition of sata array 
> storage pool
>
> For what it is worth I'll provide my experience with installing a sata

> storage pool and some observations about potential issues.
>
> Dell 2550, 1gb ram, 2 x 1ghz pentium cpus TSM server v5.2.3.2 Windows 
> 2000 sp4 160gb local scsi disk 6.4tb (16 x 400gb) local sata array 
> fiber attached IBM 3494 with 2 dedicated scsi attached 3590-e1a drives

> 600 IBM 3590J tapes about 4.6tb of TSM data stored in primary storage 
> pools about 100gb compressed client data stored daily
>
> Our 3494 was filling up and management did not want to spend the $ to 
> upgrade to 3592 drives and media. We added a 6.4tb fiber attached sata

> array which has about 5.3tb usable when configured for raid5.
>
> Clients backup daily to the local scsi diskpool and once a day we 
> migrate that storage pool to the sata diskpool. The sata diskpool is 
> defined to TSM as a sequential with maxscr=260, file size of 20gb,
> reusedelay=8 and migrdelay=33.
>
> Once a day we migrate about 2% of the sata pool to the collocated 
> tapepool and do sata file reclamation and tapepool reclamation.
>
> We see 85 to 90gb per hour throughput when migrating from the scsi 
> disk to the sata. Running two migration processes doesn't seem to 
> increase the throughput so I suspect the interface or pci bus is 
> pretty well maxed with one migration process.
>
> Sata file reclamation runs about 100gb per hour.
>
> Sata migration to tape throughput is dependent on the number of tape 
> mounts and how much tape seek there is. Process displays indicate 
> 10-20gb per hour is the norm for us. Tapepool reclamation can see as 
> high as 60gb per hour.
>
> Overall it was fairly easy to implement. As far as tape use relief we 
> are able to keep about 4tb of data on the sata so we now have less 
> than 100 tapes used in the 3494. Cost for the sata, interface, cable,
etc.
> was about $15k. No comment yet on the reliability of this brand of
sata.
>
> The only real issue I see right now is the limited throughput when 
> migrating from the sata to tape. The migration is done one sata volume

> at a time which causes some collocated tapes to be mounted multiple 
> times to receive client data from multiple sata volumes. Unless I 
> missed something, multiple concurrent migration processes are not 
> allowed
> (migpr=2 is invalid) for the sata diskpool so I'm not sure how I could

> increase this migration throughput. Perhaps I could define the sata 
> volumes larger which reduces the number of volumes to be migrated and 
> results in fewer potential multiple mounts of the same tape, a minimal

> improvement at best.
>
> Questions, comments, suggestions?
>
> --
>
> Steve Bennett, (907) 465-5783
> State of Alaska, Enterprise Technology Services, Technical Services 
> Section
>

--

Steve Bennett, (907) 465-5783
State of Alaska, Enterprise Technology Services, Technical Services
Section