ADSM-L

Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle

2006-09-14 11:00:28
Subject: Re: Best Practices DISK for DB, LOG, and STGPOOL && JigSaw Puzzle
From: "Bernaldo de Quiros, Iban 1" <iban.bernaldodequiros AT SUN DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 14 Sep 2006 15:59:31 +0100
Hi Richard,

There's a lot of great stuff here and good advices !!

But I have two last questions... 

1-Will you share the same physical disk with database and storage pool ¿?
2-Will you spread database volumes over the same physical disk or over 
different physical disks ¿? Or will you make both ¿?

Regards,

Thanks in advance,

Regards,
Ibán. 

         

-----Mensaje original-----
De: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] En nombre de 
Richard Sims
Enviado el: jueves, 14 de septiembre de 2006 15:06
Para: ADSM-L AT VM.MARIST DOT EDU
Asunto: Re: [ADSM-L] Best Practices DISK for DB, LOG, and STGPOOL && JigSaw 
Puzzle

On Sep 14, 2006, at 4:44 AM, Bernaldo de Quiros, Iban 1 wrote:

> Hi Richard,
>
> It is the first time that I do a disk assignment for TSM.
>
> As you said, I have review the documentation there are really good 
> advices, but it did not say anything about volumes sizes... For 
> example use 10 physical disk, on each of them create a 10 GB partition 
> for the database... To have 100 GB...
>
> So I do not know what volume size(partition to Spread DB, LOG,
> STGPOOL) will be suitable for DB, LOG, and STGPOOL.
>
> What volume size will be suitable for a TSM 5.3 installation ¿?
>
> Thanks in advance !!

Hi, Iban -

The guiding principle for the major random access server element, its database, 
is that you give it as many disk accessors (arms, spindles) as you can afford, 
where RAID striping tends to work best.  Partition size is not the issue here, 
but distribution of I/O.  Size the aggregate size to satisfy your current 
needs, and either create a like reserve, or make your design extensible, to 
satisfy growth demands.

Disk storage pools are also random access, but with much larger unit write 
sizes, so spreading I/O is not as much a factor, and sizing tends to be large.

The Recovery Log is essentially a sequentially written area, so spreading I/O 
is not a factor.

Be mindful of I/O path capacity in your planning: having high- 
performance disks won't help if the path to them is congested.   
Spread I/O over multiple host adapters, as can be computed from load factors.  
Some computers have multiple I/O planars (buses), where you would want to avoid 
concentrating the host adapters in one planar, which would result in needless 
constriction and imbalance.

Much of this is standard computer planning, knowing the characteristics of the 
I/O to the various TSM areas.  And remember that nothing hampers a caching 
server, such as TSM is in its database handling, like inadequate real memory, 
so don't skimp there.

    Richard Sims