ADSM-L

Re: [ADSM-L] DISK vs FILE DevClass

2013-09-19 12:24:17
Subject: Re: [ADSM-L] DISK vs FILE DevClass
From: Skylar Thompson <skylar2 AT U.WASHINGTON DOT EDU>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Thu, 19 Sep 2013 09:20:00 -0700
We had the same debate a year or so ago, and ended up making the DISK ->
FILE migration for everything except the targets of DIRMC (we figured
pure random access would be better for those).

The only problem was we had naively set REUSEDELAY to be the same as our
tape pools. We are /very/ bursty, and this caused us to run out of disk
space on occasion due to PENDING volumes sticking around. Setting this
to 0 solved that problem. We use simultaneous copy for almost all our
data, so in the event of a disk failure we can still go to copy volumes
for most of our data.

We arrived at setting MOUNTLIMIT to be 2x the number of physical
separate disk volumes. This was after tweaking it up and down and
monitoring disk utilization and I/O wait using iostat. Our back-end disk
volumes are made up of 5x 600GB 10K SAS disks in RAID-5. One of our TSM
servers has 10x of these volumes (MOUNTLIMIT=20) and the other has 15x
of these volumes (MOUNTLIMIT=30). This gives us decent throughput
without a lot of danger of disk contention. This level of control is one
of the reasons we switched to using FILE.

As for MAXCAP, we ended up at 64GB. Originally we were at the default
(2GB), but this caused our volume inventory to get huge and commands
like QUERY VOLUME and QUERY DRM were taking an excessively long time to
complete. 64GB gives us ~30 FILE volumes per filesystem, so it's only a
few hundred per host, but it still gives us enough flexibility to divvy
them up between different storage pools.

For MAXSCRATCH, we oversubscribe to a certain degree between all our
FILE storage pools, but no more than 50%. Probably in the long run it's
best not to oversubscribe at all, but like with MOUNTLIMIT this is one
of the advantages of FILE over DISK.

On 09/19/13 08:33, Zoltan Forray wrote:
We are in a transition of our SAN storage from one EMC box to another.
  Since this requires my relocating 18TB of TSM server storage, I thought I
would take this opportunity to revisit FILE devclass vs DISK, which we are
using now.

I have been reading through the Linux Server Admin Guide on the "pro's and
con's" of both devclasses.  Still not sure if it would be better to go with
FILE.   Here is some info on what this server does,.

For the server that would be using this storage, the sole backups are Lotus
Notes/Domino servers, so the backup data profile is not your usual data mix
(largely Notes TDP).

No dedupe and no plans to dedupe.
No active storage and no need for it.
4-5TB daily with spikes to 15TB on weekends - 95%+ is TDP

When creating/updating the FILE devclass, how do I calculate/guesstimate
the values for MOUNTLIMIT and MAXIMUM CAPACITY as well as the MAXIMUM
VOLUMES?

Unfortunately, the storage they assigned to me on the VNX5700 is broken up
into 8-pieces/luns, varying from 2.2TB to 2.4TB, each.

Looking for some feedback on which way we should go and why one is
preferable than the other.

--
*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


--
-- Skylar Thompson (skylar2 AT u.washington DOT edu)
-- Genome Sciences Department, System Administrator
-- Foege Building S046, (206)-685-7354
-- University of Washington School of Medicine

<Prev in Thread] Current Thread [Next in Thread>