Am 30.06.2010 17:24, schrieb Richard Sims:
The information is muddled, in that you're saying that you're
running a mixed cluster with both Linux and Netware, with both clients (at
different levels) performing backups of the same data, ostensibly with
the same node name. I would not expect good results from that.
I agree that the additional complexity which comes from running two
operating systems in one HA cluster environment is challenging. That is
why I ask for help on this list.
But then I do consider the backup of cluster volumes to be a basic
feature of any enterprise level backup environment. Tivoli supports
this, and we have been using this feature for many years with good
success on Netware clusters. It is virtually impossible to provide a
cluster volume with a different nodename on each host. In a worst case
scenario this would multiply backup time and number of tapes needed by
the number of hosts. Restoring from backup will be very complicated and
demanding in a setup where one has to remember on which host a volume
was running at a given time in the past.
One query you should do on the TSM server is "Query FIlespace TEST
Format=Detailed" to survey the filespace characteristics, seeing if
there is some mixture of Unicode (as in UTF-8) and non-Unicode - and
particularly if any filespaces are both, where TSM will default to
trying to use the non-Unicode instance.
Thank you very much indeed for this advice. With our main TSM server
admin enjoying his summer vacation I will have to wait until I have
access to the server logs again. But I will come back with this information.
On the client side, Netware clients show two or three filespaces
depending on whether NTW:UTF-8 being enabled or not, e.g.
tsm> query filespace -detail
# Last Incr Date Type fsID Unicode File Space Name
--- -------------- -------- ----- ------- ----------------
1 06/22/2010 11:14:10 NSS 9 No /media/ndss/TEST
2 06/29/2010 17:26:19 NTW:UTF-8 11 Yes TESTCLUSTER/TEST:
3 06/28/2010 11:36:30 NTW:LONG 10 No TESTCLUSTER/TEST_OLD:
tsm>
On this node the filespace of type NSS was created prior to moving
NTW:LONG to TESTCLUSTER/TEST_OLD and using NTW:UTF-8 on Netware. Access
from the Linux client is denied since 29th of June.
What you're doing is on the fringes of product utilization. You may
have to contact TSM Support to get further. Check your dsmerror.log for
further indications of underlying problems, as well as the TSM server
Activity Log for problem indications at session initiation attempts. A
client trace (see TSM Problem Determination Guide) would reveal more.
Now that's intersting and instructive. I was not aware of the dsmtrace
utility. Below is what might be the relevant bit of the session. I will
still have to inspect the server log.
Günther
# dsmc -traceflags=service -tracefile=/root/dsmtrace-ndps.txt
IBM Tivoli Storage Manager
Command Line Backup/Archive Client Interface
Client Version 5, Release 5, Level 2.7
Client date/time: 07/01/10 16:46:44
(c) Copyright by IBM Corporation and other(s) 1990, 2009. All Rights
Reserved.
Node Name: TEST
ANS1357S Session rejected: Downlevel client code version
# cat /root/dsmtrace-ndps.txt
[...]
01.07.2010 16:42:23.104 [006164] [3074874192] : session.cpp
(3215): Recv Verb:
01.07.2010 16:42:23.104 [006164] [3074874192] : session.cpp
(3216): Length: 25 Code: 0000001C Type: <- SignOnResp
01.07.2010 16:42:23.104 [006164] [3074874192] : cucommon.cpp
(3013): cuSignOnResp: auth: On, regMethod: Closed, compress: Compress_CD
01.07.2010 16:42:23.104 [006164] [3074874192] : cucommon.cpp
(3023): archDel: Yes, backDel: No, disasterBackDel: No
01.07.2010 16:42:23.104 [006164] [3074874192] : cucommon.cpp
(3031): encryption: Encrypt_CD, txnGroupLimit: 4096
01.07.2010 16:42:23.104 [006164] [3074874192] : cucommon.cpp
(3037): permPlatform: 'Linux86', resultCode: 7
01.07.2010 16:42:23.104 [006164] [3074874192] : cucommon.cpp
(3064): cuSignOnResp: Server rejected session; result code: 57
01.07.2010 16:42:23.104 [006164] [3074874192] : sesscntl.cpp
(3380): sessOpen: Error 57 receiving SignOnResp verb from server
01.07.2010 16:42:23.104 [006164] [3074874192] : session.cpp
(7396): sessClose: Transitioning: sSignedOn state ===> sInit state
01.07.2010 16:42:23.104 [006164] [3074874192] : commtcp.cpp
(2635): TcpClose(): Closing socket
01.07.2010 16:42:23.104 [006164] [3074874192] : pscomtcp.cpp
(1065): psTcpClosesocket(): Socket 5 (IPv4) closed with rc=0, errno=0
01.07.2010 16:42:23.104 [006164] [3074874192] : commtcp.cpp
(2654): TcpClose(): Deallocating send buffer
01.07.2010 16:42:23.104 [006164] [3074874192] : session.cpp
(4094): sessClose: Session closed.
[...]
|
