We're running about 200 nodes, another 320-ish (it varies day by day) VMs with an average daily intake of 4.2 TB over the past 30 days. We have a high change-rate, however, and our occupancy is 'only' 270 TB and around 110,000,000 objects stored.
We back up directly to the dedup pool, which resides on a mix of 3 and 4 TB NL-SAS disks hosted on a V7000 and a DCS3700. Total spindle count is 84 for this pool. TSM DB and active log is stored on SSD (again hosted on the V7000) and our TSM server is a P740 with 15 cores allocated to the TSM LPAR and 125 GB of RAM. We are in the process of migrating our TSM server to the new-shiny Power 822 boxes, which will up our core-count to 18 Power8 cores and ~250GB of RAM (depending on how much is lost to VIO servers) How are you calculating the 2-300k IOPS? What's the spindle count on the Hitachi storage device? We've been having some troubles with our database, which is ~2.3 TB (though yours must be huge if you're managing 500 million objects). Are you doing offline db reorgs every six months or so? We've found that online reorgs are pretty much impossible, they fill the active log and crash the server instance. Matthew McGeary Technical Specialist PotashCorp - Saskatoon 306.933.8921 From: Stefan Folkerts <[email protected]> To: [email protected] Date: 07/03/2014 05:13 AM Subject: Re: [ADSM-L] TSM 7.1 and dedup "chunking" issues Sent by: "ADSM: Dist Stor Manager" <[email protected]> 1.5TB seems like a very reasonable amount for these spec's, if the amount of managed deduped data isn't above the 400TB you seem well within the configuration maximums that IBM provides. On Thu, Jul 3, 2014 at 12:02 AM, Bent Christensen <[email protected]> wrote: > This server manages 200 clients, approx. 500.000.000 files occupying > approx. 800 TB, a mixture of various databases, Exchange and files, all > Windows clients. Not all client data end up in a dedup pool. > > Daily backup ingest to the dedup pool is 1.5 TB on average. We aim to > receive backup data on an internal SAS array, backup to tape copypool and > then migrate to the dedup pool. The dedup pool storage is Hitachi AMS, 2000 > family with SATA disks, fiber attached, should be able to deliver at least > 2-300K IOPS in this configuration. > > - Bent > > -----Original Message----- > From: ADSM: Dist Stor Manager [mailto:[email protected]] On Behalf Of > Stefan Folkerts > Sent: Wednesday, July 02, 2014 2:13 PM > To: [email protected] > Subject: Re: [ADSM-L] TSM 7.1 and dedup "chunking" issues > > Also : > > >>32 cores, 256 GB RAM, DB and activelog on SSD. > > Wow, that's pretty serieus. > > Also, if I might ask, what is your daily backup/archive ingest, how much > data do you manage and what type of disk (system/config) do you use for > your filepool storage? > > > > On Wed, Jul 2, 2014 at 12:58 PM, Bent Christensen <[email protected]> wrote: > > > Hi all, > > > > I remember noticing that there were some dedup housekeeping (removal > > of dereferenced chunks) issues with TSM Server 6.3.4.200 and that a > > fix was released. We used 6.3.4.200 for a while as stepping stone on > > our road from > > 5.5 to 7.1 but without the fix. > > > > Now, on 7.1, I am seeing some stuff that makes me worry a bit - > > initiated by a gut feeling that there are more data in my dedup pool > > than there should be. > > > > SHOW DEDUPDELETEINFO shows that I have +30M chunks waiting in queue > > and the number is increasing. It also shows that I right now have 8 > > active worker threads with a total of 5.8M queued, but only approx. > > 4000 chunks/hour get deleted. > > > > Any knowing if these numbers make sense? > > > > We use a full-blown TSM server on Windows, 32 cores, 256 GB RAM, DB > > and activelog on SSD. > > > > - Bent > > >
