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@VM.MARIST.EDU] On Behalf Of Paul Zarnowski Sent: Thursday, November 14, 2013 2:33 PM To: ADSM-L@VM.MARIST.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@VM.MARIST.EDU] On Behalf Of >Sergio O. Fuentes >Sent: Wednesday, November 13, 2013 10:32 AM >To: ADSM-L@VM.MARIST.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: p...@cornell.edu 719 Rhodes Hall, Ithaca, NY 14853-3801