ADSM-L

Re: [ADSM-L] *EXTERNAL* Re: Multiple NFS mounts to same DataDomain

2017-02-14 13:05:42
Subject: Re: [ADSM-L] *EXTERNAL* Re: Multiple NFS mounts to same DataDomain
From: "Rhodes, Richard L." <rrhodes AT FIRSTENERGYCORP DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 14 Feb 2017 18:01:57 +0000
I see.

You can remove the dir from the devclass, but TSM will still access existing 
volumes on that dir.  And then a procedure to movedata them.

My assumption was that you wouldn't be able to remove the dir from the devclass 
until while there were vols on it, and I couldn't think of how to get rid of 
the vols on the dir since it was in use.

Great Info!

Thanks!

Rick



-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Thomas Denier
Sent: Tuesday, February 14, 2017 11:47 AM
To: ADSM-L AT VM.MARIST DOT EDU
Subject: *EXTERNAL* Re: Multiple NFS mounts to same DataDomain

I have successfully removed directories from file device classes a number of 
times. The sequence of events was as follows:
1.Remove the directory from the list in the device class definition to prevent 
allocation of new scratch volumes on the directory.
2.List filling volumes on the directory and make them read only, preventing 
appends to existing volumes on the directory.
3.Run "move data" commands to relocate the contents of volumes to other 
directories.
4.Wait for database backups and pending volumes to age off.

The Linux administrator thought step 3 would have better overall throughput 
with multiple streams of "move data" commands. I used the "-P" option of 
"xargs" to manage the multiple streams.

Thomas Denier,
Thomas Jefferson University

-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of 
Rhodes, Richard L.
Sent: Tuesday, February 14, 2017 08:35
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [ADSM-L] Multiple NFS mounts to same DataDomain

Arnaud's discussion on the another thread is SO interesting (Availability for 
Spectrum Protect 8.1 server software for Linux on power system).

It got me thinking of our problems . . .

> NFS, whose performance is not that good on AIX systems

Agreed!!!  After getting DataDomain system and using NFS we were/are VERY 
unhappy with the NFS performance.

Our Unix admins worked with IBM/AIX support, and finally got an admission that 
the problem is AIX/NFS using a single TCP socket for all writes.  The 
workaround was to use multiple mount point to the same NFS share and spread  
writes (somehow) across them.  He did this and got higher throughput.

So now I'm wondering if we could use multiple NFS mounts to the same DD for our 
file device pools.

  aix:  /DD/tsm1/mnt1        dd: /data/col1/tsm1/mnt1
        /DD/tsm1/mnt2            /data/col1/tsm1/mnt2
        /DD/tsm1/mnt3            /data/col1/tsm1/mnt2

Then use multiple dir's for the file device devclass:
   define devclass DDFILEDEV devtype=file 
dir=/DD/tsm1/mnt1,/DD/tsm1/mnt2,/DD/tsm1/mnt3

According to the link to dsmISI again, TSM will roughly balance across the 
multiple mount points, hopefully giving better write throughput.  I've been 
VERY reluctant to try this since it appears once you add a dir to a file device 
devclass, it's there forever!


I'm curious if anyone is doing this.

Rick
The information contained in this transmission contains privileged and 
confidential information. It is intended only for the use of the person named 
above. If you are not the intended recipient, you are hereby notified that any 
review, dissemination, distribution or duplication of this communication is 
strictly prohibited. If you are not the intended recipient, please contact the 
sender by reply email and destroy all copies of the original message.

CAUTION: Intended recipients should NOT use email communication for emergent or 
urgent health care matters.



-----------------------------------------
The information contained in this message is intended only for the personal and 
confidential use of the recipient(s) named above. If the reader of this message 
is not the intended recipient or an agent responsible for delivering it to the 
intended recipient, you are hereby notified that you have received this 
document in error and that any review, dissemination, distribution, or copying 
of this message is strictly prohibited. If you have received this communication 
in error, please notify us immediately, and delete the original message.
<Prev in Thread] Current Thread [Next in Thread>