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
|
