I've just done a reconfig of my DB and LOG volumes that flies in the
face of conventional wisdom - but it works!
First, the essential parts of my environment:
TSM Server 5.2.6.0 on AIX 5.2. Disk is an IBM FASTT 600 Turbo
with the main drawer and (3) EXP-710 drawers (switched disk drawers).
All 4 drawers are filled with (14) 73GB 15K FC drives.
I have all Disk pools on here. RAID arrays are built with ONE disk
from each drawer (max redundancy). I had moved from older
disk system to this one about 9 months ago.
For layout of DB and LOG at that time I had used standard method,
layout out over many disks. So, I had about 8 GB LOG and 80GB DB
at that time. I used RAID 0, one disk for each. So had 2 disks
for log, one main and one mirrored. I used 8 disks for DB, 4 primary
and 4 mirror. On the FAST Array, I carved out 10GB LUNS.
At AIX level these 10GB LUNS were separate disks and I setup
simple jfs filesystems on them. All mirroring was done at TSM level.
I then at TSM level defined 1GB LOG vols and mirrored. I defined 5GB
DB vols, two per filesystem and therefore had 16 DB vols and then 16
mirrors.
(Also I have about 400 clients of all types and backup about 1.5 TB
per day.)
WHAT I CHANGED (and why):
My 80 GB DB had crept up to 83% utilized on me. We had a slightly flaky
disk on the FASTT that was one of my LOG disks. I had realized from
the start that if one of these disks went, would take AIX and TSM work
to rebuild. As this entire system was working well for me, I wanted to
eliminate that problem in case of disk failure and also conserve disk space.
So I created a 10GB LUN in extra space on one Disk pools Raid 5 Array and
mirrored my LOG over to it and deleted the old volumes at TSM level. I noticed
no problem running this way! My 8 GB log normally only hits 10% max, with
occasional hits or 25-50% with client problems, and I also knew that log
activity
is not heavy I/O.
So with this down, I created a RAID 5 array across 4 FASTT disks. Then for
apples
to apples comparison, I created 10 GB LUNS on FASTT like current DB uses. And
created on AIX the same way also. I then at TSM level defined, mirrored over to
the new DB vols and deleted all old mirrors to RAID 0 disks for half my DB.
Ran 24
hours with no problem. Then I moved the rest of the DB over the next day.
I then ran about a week with this and had no problems. Backups ran normal
and easiest to measure is FULL DB Backup and Expiration. No increase in time!
I then in same fashion increased my DB from 80GB to 100GB to get utilization
down to 67%. That is, used same RAID 5 array and same LUN and DB vol size.
I still get no increase in time for DB backup (well one minute now!) and
expiration.
No noticeable change in backups either.
CONCLUSION?
So, I have saved disks and made disk failure transparent, our guy that
handles replacements can do this in minutes and I don't have to get involved.
Maybe old philosophy has been overcome by newer/faster disks and disk systems?
I now have no TSM mirror for LOG or DB. Old philosophy was that TSM mirror
had "some slight extra protection" for TSM. Wonder if this is still true or
not these
days? Would basically have to use more disks for this and am on RAID 5 for both
now.
Comments anyone?
David B. Longo
System Administrator
Health First, Inc.
3300 Fiske Blvd.
Rockledge, FL 32955-4305
PH 321.434.5536
Pager 321.634.8230
Fax: 321.434.5509
david.longo AT health-first DOT org
##############################################################
This message is for the named person's use only. It may
contain confidential, proprietary, or legally privileged
information. No confidentiality or privilege is waived or
lost by any mistransmission. If you receive this message
in error, please immediately delete it and all copies of it
from your system, destroy any hard copies of it, and notify
the sender. You must not, directly or indirectly, use,
disclose, distribute, print, or copy any part of this message
if you are not the intended recipient. Health First reserves
the right to monitor all e-mail communications through its
networks. Any views or opinions expressed in this message
are solely those of the individual sender, except (1) where
the message states such views or opinions are on behalf of
a particular entity; and (2) the sender is authorized by
the entity to give such views or opinions.
##############################################################
|
