All I can say is what I've observed...
Question #4) TSM looks to preallocate space on and direct new inbound
traffic to a volume not currently in use within a storage pool. This is why
I try to have as many volumes in a storage pool as I expect concurrent
inbound sessions (within reason). 1 is a really bad idea... I would think
5000 is also a really bad idea... I try to balance between the size of the
inbound files and the number of inbound sessions. That is, if you have a
big SAP/oracle system pushing 30 GB files at you, having 5 GB volumes is a
little small... Just remember, internally TSM is placing locks and holding
locks as inbound sessions are moving data until the transactions get
committed to the db... so 2 sessions with fighting locks against a single
volume will run slower than 2 sessions each going to their own storage pool
volume holding locks against only those storage pool volumes.
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Robert Clark
Sent: Thursday, February 17, 2011 2:43 PM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [ADSM-L] How many disk volumes are too many?
Hi Zoltan,
First group of questions: What disk type / RAID type / RAID rank / LUN
carving strategy is in place? How many paths do you have? What is the
queue depth? (Multipath load balancing stragegy?) (And array controller
settings too.)
Second group of questions: What disk_group/volume_group
striped_plex/striped_logical_volume filesystem/raw_logical_volume type
stuff is done to destroy the sequential nature of the I/O. (How many LUNs
/ how many I/O allowed to pend per LUN?)
Third group of questions: Is running one dsmfmt process per file
system/plex in parallel and watching the max I/O tell you anything about
what the host/subsystem will do under a real backup load?
Fourth group of questions: What algorithm does TSM use while figuring out
which session gets which volume? What does performance look like during
migration and backup stgpool?
Fifth group: What does the TSM perf guide suggest? What does the disk
vendor's perf guide suggest? Is your environment anything like what the
perfs guides are based on?
Sixth group: What is good for the sanity of the TSM admin? (50 volumes is
nice, 5000 makes the admin crazy?)
Is there some common convention, in case someone inherits your environment
down the road?
[RC]
From:
Zoltan Forray/AC/VCU <zforray AT VCU DOT EDU>
To:
ADSM-L AT VM.MARIST DOT EDU
Date:
02/17/2011 10:13 AM
Subject:
[ADSM-L] How many disk volumes are too many?
Sent by:
"ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
I am aware of the TSM design that says the more disk volumes you have, the
more it will spread out the I/O for better performance. I also realize a
lot of this doesn't really apply what with RAID-5, EMC SAN, multi-terabyte
storage, etc.
So, at what point does having lots of smaller volumes (for a disk LZ), not
give you any more benefit, I/O wise?
I have a 5.3TB SAN space on my new 6.2.2.0 server. Originally, I started
formatting 200GB volumes then moved to 300GB, up to 25-volumes.
Now I am adding another 5.3TB space and was wondering if I should continue
with 300GB or jump to 500GB?
Simultaneous sessions should not be an issue since most of these backups
are Domino TDP and therefore single thread. I don't think there is a peak
of more than 60-simultaneous sessions.
The TSM server is a Dell T710 with 48GB RAM and 15K internal disk for the
DB & Logs.
Your thoughts?
Zoltan Forray
TSM Software & Hardware Administrator
Virginia Commonwealth University
UCC/Office of Technology Services
zforray AT vcu DOT edu - 804-828-4807
Don't be a phishing victim - VCU and other reputable organizations will
never use email to request that you reply with your password, social
security number or confidential personal information. For more details
visit http://infosecurity.vcu.edu/phishing.html
U.S. BANCORP made the following annotations
---------------------------------------------------------------------
Electronic Privacy Notice. This e-mail, and any attachments, contains
information that is, or may be, covered by electronic communications privacy
laws, and is also confidential and proprietary in nature. If you are not the
intended recipient, please be advised that you are legally prohibited from
retaining, using, copying, distributing, or otherwise disclosing this
information in any manner. Instead, please reply to the sender that you have
received this communication in error, and then immediately delete it. Thank
you in advance for your cooperation.
---------------------------------------------------------------------
|
