The size of storage is not enough information to size a system. The number of sessions determines system size.
If you have four clients, 1 gig per night, you could run 8GB RAM, Core2 2GHz and be okay. Realistically, 32GB per instance is good. db2sysc will use about 20GB per instance if it's available. This handles a couple hundred clients, deduplication, etc. As for processors, one processor for every 2 DB directories, plus one processor for TSM internals is minimal. If you will have high I/O, then one hardware thread for every IDENTIFY DUPLICATES process is good. If you will use client-side dedupe most of the time, then you you only use IDENTIFY DUPLICATES when you move data into the pool server side. Higher GHz matters for the identify processes, though branch prediction is still important (POWER5 or POWER7 are better than POWER6) Higher hardware thread counts matter for client session responsiveness (POWER7 uses fewer cores than POWER6/POWER5) Higher I/O backplane matters for amount of raw data coming in (Low end POWER wins over low-end Intel) Higher IOPS for the DB volumes are necessary to keep clients from slowing down. (hash compares) Lower network latency matters for client performance (hash compares) With friendly Regards, Josh-Daniel S. Davis OmniTech Industries On Thu, Apr 26, 2012 at 8:43 AM, Francisco Molero <fmol...@yahoo.com> wrote: > Hi colleagues, > > > I am going to implement a very big disk pool with dedup around 100 TB. TSM > disk Storage pool ( neither VTLs nor DataDomain) . Somebody knows what TSM > server I need ( RAM and CPU) or what ratio can I hope... I am thinking > about source Dedup... > > > Any experiences? > > > Thanks.. >