I believe there is still a reason to mirror at the TSM level. If you mirror
at the hardware level only and TSM writes a corrupt entry to the DB or log,
you are hosed since the hardware mirror will write it to both copies. If
TSM is doing the mirror, it can see that it had a problem writing to one
copy and not write the corrupt data to the second copy. TSM can then use
the good copy to fix the corrupt mirror. Now I do not know how or when this
case can come up but that is the reason I was told to mirror at the TSM
level. We use EMC for the storage. All our EMC storage is mirrored or
raided. We then also mirror at the TSM level. This is over kill but we do
not have any unprotected disks to use so we double do it. Have not had a
problem but we may be wasting disks.
--
Phillip
320-4462
-----Original Message-----
From: David Longo [mailto:David.Longo AT HEALTH-FIRST DOT ORG]
Sent: Friday, January 20, 2006 1:02 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] DB & LOG Volume layout - new
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.
##############################################################
*********************************************************************
This message and any attachments are solely for the intended recipient. If you
are not the intended recipient, disclosure, copying, use or distribution of the
information included in this message is prohibited -- Please immediately and
permanently delete.
|
