We want clients to backup directly to disk (no tape). All of our
backups do not end up on the sequential disk pool (it's actually not
SATA, but FC SCSI). Some end up on tape as mentioned.
If we went directly to the sequential disk pool, files bigger than 2GB
would go to tape from the client - we don't want that. This would also
mean that the stgpool backups would require tape mounts.
I've seen an APAR (which I've mentioned on the list before) about some
issues backing up directly to sequential files - another reason.
I agree it seems like extra work but the migration from internal disk to
our sequential file pool is currently taking about 1.5 hours to do 282
GB of compressed client data - not really an issue in our environment.
One other thing this buys us is added redundancy - if something went
wrong with the sequential file pool we could still run a day of backups
(and we have some backups running hourly throughout the day).
One thing I don't like about this setup is clients backup to disk
overnight and we currently don't migrate this pool until 16:30 the next
day (so all files will be on disk during the day) - but this means we
don't get multisession restore from those backups on the DISK pool.
This is a work in progress so I'm open to suggestions ...
Thanks,
Tim Rushforth
City of Winnipeg
-----Original Message-----
From: Andy Carlson [mailto:andyc AT ANDYC.CARENET DOT ORG]
Sent: Monday, March 14, 2005 10:28 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: SUSPECT: (MSW) review of recent addition of sata array
storage pool
Can I ask a silly question: Why do you back up to a disk pool, then
migrate to a disk pool. It seems like it might be more efficient to
back up to the SATA pool directly. Thanks!
Rushforth, Tim wrote:
> We have a setup like:
> 2 x Windows 2003, 5.2.2.4 Server
> Clients backup to local DISK stgpool, this migrates to a Sequential
File
> Disk Pool with a maxsize and this migrates to tape (3584 LTO1 and
LTO2).
>
> We don't collocate the sequential file pool. But we really never
> migrate from sequential file to tape. The idea here is we configure
> maxsize so that all small files will be on disk - only large will be
on
> tape. This takes a bit to configure the size based on the amount of
> storage you have but to me it is the best situation.
>
> If you don't have enough disk to keep all files, only store large ones
> on tape.
>
> On one of our servers the maxsize is set at 2GB and we currently have
> 186 files occupying 705 GB on tape.
>
>>>From Occupancy table:
>
> STGPOOL_NAME NUM_FILES PHYSICAL_MB LOGICAL_MB
> BACKUP-DISK Total 17,156,200 4,161,023 4,147,439
> BACKUP-LTO Total 186 705,469 705,469
>
> With this setup everything flies, mutli-session client restores,
> migration to seq file disk, onsite plus offsite reclamation.
>
> Tim Rushforth
> City of Winnipeg
>
> -----Original Message-----
> From: PAC Brion Arnaud [mailto:Arnaud.Brion AT PANALPINA DOT COM]
> Sent: Monday, March 14, 2005 9:59 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: SUSPECT: (MSW) review of recent addition of sata array
> storage pool
>
> 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
>
>
>
--
Andy Carlson - Senior Technical Specialist
BJC Healtcare
------------------------------------------------------------------------
---
Gamecube:$150,PSO:$50,Broadband Adapter: $35, Hunters License:
$8.95/month,
The feeling of seeing the red box with the item you want in
it:Priceless.
|
