Pina,
I recently discussed with IBM the optimal design of our disk storage
pools as we were moving all of our ADSM datasets from older DASD to RAMAC3.
This was the heart of their reply. I hope you find it helpful.
****************************************************************************
****************
"DB configuration depends on what you want to maximize: performance or
availability. Ideally you want to spread the database and recovery log
(define multiple db and recovery volumes on separate devices) for
performance reasons (simultaneous access to different parts of the
db/rl) and also place the mirror volumes on different devices to
insure that a failure on a single device does not affect more than
one db/rl volume.
For storage pools, it depends on how many disk storage pools you are
defining, the configuration of the storage pool hierarchy, and if
any of the hierarchy level is tape. At the first level of the
hierarchy, you want the maximum number of devices per storage pool
to be able to support a large number of concurrent clients.
So a single storage pool with lots of disk is ideal.
However, for disk-to-tape migration, you want to avoid a "many-disks" to
"many tapes" configuration to minimize the amount of disk contention
between each migration process. Therefore, multiple storage pools
works best when you have a disk-to-tape hierarchy (each migration
process migrates data from an exclusive disk storage pool--set of
devices)."
****************************************************************************
***********
Good luck,
Dan T.
----------
> From: Barton, Pina <pbarton AT KMART DOT COM>
> From: Barton, Pina <pbarton AT KMART DOT COM>
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Disk Storage Pool Configuration
> Date: Friday, August 29, 1997 10:33 PM
>
> Hi,
> We are considering redesigning our storage pools because of problems
> we've had and to simplify our environment. Here's our current
> environment (server is AIX 4.1.4 ADSM 2.5.1.12):
>
> SSA #1 SSA #2
> LVL1 LVL2
> DISK01 DISK02
> FILE01 FILE02
>
> TAPE01 TAPE02
>
> The 2 DISK01/02 pools are DEVTYPE=DISK (they are for files <5 MB).
> The FILE01/02 pools are DEVTYPE=FILE (they are for files >5 MB).
>
> This was originally set up with 2 objectives:
>
> 1. If an SSA adapter was lost, maintain access to 1/2 disks. We have
> since
> found out that all the disks are cabled through both adapters and
> if we lose
> 1 adapter, all our disk is still available. Therefore, 'splitting'
> our pools down
> the middle for availability purposes is not an issue.
>
> 2. The file pools are supposed to be better performing for large files
> (simulates
> streaming, i.e. writing to a tape drive). However, since we have
> only 2
> drives, our DISK01/DISK02 pools migrate to the FILE01/FILE02 pools
> when
> they reach a threshold (FILE01/FILE02) migrate to TAPE01/TAPE02.
> Therefore it seems like we are potentially moving files a lot
> (first to write
> the small ones into the DISK pools, a second time to move these
> small
> files to the FILE pools, and finally a third time to tape when the
> FILE
> pools reach threshold).
>
> Also, we've experienced problems where a node points to a disk pool
> (such as
> disk02 pool) for backup and runs out of space so the backup fails, yet
> there is plenty of space on the other pools (i.e. disk01). It's also a
> manual balancing act for us to figure out when we add a new node which
> 'side' to put it on.
>
> So, I've convinced myself we want to switch to one pool. But, I'm
> curious on others out there.. Does anyone else run 'split' pools like
> we do, or file pools? And if so, what has been your experience? Has
> anyone ever attempted to combine a split environment into a single
> storage pool, like we are going to?
>
> Many thanks.
|
