Paul,
I describe my copypool setup in a previous reply, last Friday.
If you lost it somehow, it is on adsm.org.
But quickly, they are on virtual volumes. I have never seen any issues
related to the primary pool volume size.
- bill
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Paul Zarnowski
Sent: Monday, November 18, 2013 9:35 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: TSM Dedup stgpool target
One other question, if you don't mind Bill: Do you have Copy Storage Pools?
If so, are they on tape or file? If tape, is the small volume size on the
primary pool an issue? I.e., does TSM optimize output tape mounts?
Thanks.
..Paul
At 05:48 PM 11/14/2013, Colwell, William F. wrote:
>Paul,
>
>I am using 4 GB volumes on the 15k disks (aka ingest pool). Since each disk
>is ~576 GiB
>and there are 16 disks assigned to this server, that's a lot of volumes!
>
>On the sata based pools I am using 50 GiB volumes.
>
>All volumes are scratch allocated not pre-allocated.
>
>I know scratch volumes are supposed to perform less well, but I haven't heard
>how much less and I did ask.
>I couldn't run the way I do and manage pre-allocation. There are 2 very big
>and very busy instances on the
>processor and both share all the filesystems. And each instance has multiple
>storage hierarchies so
>mapping out pre-allocation would be a nightmare.
>
>thanks,
>
>- bill
>
>-----Original Message-----
>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
>Of Paul Zarnowski
>Sent: Thursday, November 14, 2013 2:33 PM
>To: ADSM-L AT VM.MARIST DOT EDU
>Subject: Re: TSM Dedup stgpool target
>
>Hi Bill,
>
>Can I ask what size volumes you use for the ingest pool (on 15k disks) and
>also on your 4TB sata pool? I assume you are pre-allocating volumes and not
>using scratch?
>
>Thanks.
>..Paul
>
>At 02:13 PM 11/14/2013, Colwell, William F. wrote:
>>Hi Sergio,
>>
>>I faced the same questions 3 years ago and settled on the products from
>>Nexsan (now owned by Imation) for
>>massive bulk storage.
>>
>>You can get a 4u 60 drive head unit with 4TB sata disks (the E60 model), and
>>later attach 2 60 drive expansion
>>units to it (the E60X model).
>>
>>I have 3 head units now, not with the configuration above because they are
>>older.
>>
>>1 unit is direct attached with fiber and the other 2 are san attached. I am
>>planning to convert the
>>direct unit to san attached to facilitate a processor upgrade.
>>
>>There are 2 server instances on the processor sharing the filesystems. The
>>OS is Linux rhel 5.
>>
>>All volumes are scratch allocated.
>>
>>The backups first land on non raid 15k 600GB disks in an Infortrend device.
>>The copypooling is done from there
>>and also the identify processing. Then they are migrated to the Nexsan based
>>storagepools.
>>
>>There is also a tape library. Really big files are excluded from dedup via
>>the stgpool MAXSIZE parameter and
>>land on a separate pool on the Nexsan storage which then migrates to tape.
>>
>>Hope this helps,
>>
>>Bill Colwell
>>Draper Lab
>>
>>-----Original Message-----
>>From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
>>Of Sergio O. Fuentes
>>Sent: Wednesday, November 13, 2013 10:32 AM
>>To: ADSM-L AT VM.MARIST DOT EDU
>>Subject: TSM Dedup stgpool target
>>
>>In an earlier thread, I polled this group on whether people recommend going
>>with an array-based dedup solution or doing a TSM dedup solution. Well, the
>>answers came back mixed, obviously with an 'It depends'-type clause.
>>
>>So, moving on... assuming that I'm using TSM dedup, what sort of target
>>arrays are people putting behind their TSM servers. Assume here, also, that
>>you'll be having multiple TSM servers, another backup product, *coughveeam
>>and potentially having to do backup stgpools on the dedup stgpools. I ask
>>because I've been barking up the mid-tier storage array market as our
>>potential disk based backup target simply because of the combination of cost,
>>performance, and scalability. I'd prefer something that is dense I.e. more
>>capacity less footprint and can scale up to 400TB. It seems like vendors get
>>disappointed when you're asking for a 400TB array with just SATA disk simply
>>for backup targets. None of that fancy array intelligence like auto-tiering,
>>large caches, replication, dedup, etc.. is required.
>>
>>Is there another storage market I should be looking at, I.e. really dumb raid
>>arrays, direct attached, NAS, etc...
>>
>>Any feedback is appreciated, even the 'it depends'-type.
>>
>>Thanks!
>>Sergio
>
>
>--
>Paul Zarnowski Ph: 607-255-4757
>Manager of Storage Services Fx: 607-255-8521
>IT at Cornell / Infrastructure Em: psz1 AT cornell DOT edu
>719 Rhodes Hall, Ithaca, NY 14853-3801
--
Paul Zarnowski Ph: 607-255-4757
Manager of Storage Services Fx: 607-255-8521
IT at Cornell / Infrastructure Em: psz1 AT cornell DOT edu
719 Rhodes Hall, Ithaca, NY 14853-3801
|
