>> On Fri, 26 May 2006 22:43:04 -0400, Robin Sharpe <Robin_Sharpe AT BERLEX DOT
>> COM> said:
> One other recommendation, which I did... do not run all of your TSM
> instances as root (you are on Unix , right?). Doing so, if you do a
> "ps -ef|grep dsmserv" command, you can't tell which process belongs
> to which server without doing more research .
My solution to the same concern was to always always start my servers
through a script, which added '-- SERVERNAME' to the command line.
root 397336 1 0 Dec 03 - 8801:30 dsmserv quiet -- COPIES
root 696478 1 31 Jan 01 - 6458:42 dsmserv quiet -- CTRL
root 741538 1 16 Jan 05 - 27056:49 dsmserv quiet -- EXT
root 757808 1 0 Mar 29 - 2766:05 dsmserv quiet -- GLMAIL03
root 761968 1 31 Jan 19 - 17946:45 dsmserv quiet -- INT
root 790706 1 0 Apr 28 pts/7 1503:28 dsmserv quiet -- GLMAIL02
root 835662 1 0 Dec 29 - 969:21 dsmserv quiet -- WEBCT
root 868510 1 0 Apr 07 - 2136:54 dsmserv quiet -- GLMAIL01
root 946258 1 0 Apr 28 pts/7 1246:19 dsmserv quiet -- GLMAIL04
root 962606 1 6 Apr 27 pts/7 10684:18 dsmserv quiet -- ERP
The different-user solution was suggested to me, but I have the
opinion that there would be more pain in moving resources from server
'X' to server 'Y' than would be saved.
> This will also prevent the wrong TSM from accessing another TSM's
> storage... this can be easy to do if you use raw logical volumes as
> we do.
Heh.
And my solution to this is through nomenclature. So, for instance,
for the 'ERP' server, the lvs have the 'erp' string in a well-defined
place.
-bash-2.05b$ lsvg -l tsmdat | grep -i erp
terpdat000 jfs 45 45 1 open/syncd N/A
terpdat001 jfs 45 45 1 open/syncd N/A
terpdat002 jfs 45 45 1 open/syncd N/A
terpdat003 jfs 45 45 1 open/syncd N/A
terpdat004 jfs 45 45 1 open/syncd N/A
terpdat005 jfs 45 45 1 open/syncd N/A
terpdat006 jfs 45 45 1 open/syncd N/A
terpdat007 jfs 45 45 1 open/syncd N/A
terpdat008 jfs 45 45 1 open/syncd N/A
terpdat009 jfs 45 45 1 open/syncd N/A
terpdat010 jfs 45 45 1 open/syncd N/A
terpdat011 jfs 45 45 1 open/syncd N/A
As robin notes, this doesn't -prevent- "erp" from stomping on
something which should belong to "int", but it makes it harder to do
such a thing accidentally.
In my organization, we're trying very hard to keep unified namespaces
of IDs; Adding an additional TSM instance userid might have
campus-wide namespace implications. Consequently, I resist their
proliferation rather strongly.
- Allen S. Rout
|
