ADSM-L

Accessing 3494 library in DR senario

2005-03-29 10:47:04
Subject: Accessing 3494 library in DR senario
From: Lawrence Clark <Larry_Clark AT THRUWAY.STATE.NY DOT US>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 29 Mar 2005 10:47:58 -0500
Our DR tests of using a backup TSM server with the exisiting 3494 tape
libraries ran into problems.

The setup:
- both the DR TSM server and the Prod TSM server are connected to the
switch and the libraries (lmcp) points and the devices show active.
However, the addressing on each server is slightly different.
The test:
- to test the prod DB is restored to the DR server, which works fine.
The problem continues to be accessing the library.
- after the last test failure I took an hour during the daily TSM prod
cycle and:
   1). brought down the PROD TSM and kept it down during the test
   2).  recycled the DR TSM  ( with the hostname and I.P. address of
the PROD TSM) so it could establish the addressing from scratch
   3). brought up the DR TSM, then brought up TSM. Unfortunately from
my previous test I had deleted the library defs and so could not test
them coming up automaticly. However, I was able to successfully able to
define the library to TSM this time, but then it saw all the volumes in
the library as  checked out. I was noit able to define this previously
when I had not thought it necessary to recycle the DR TSM. Kept getting
I/O errors.

My thinking is:
- if the library and device definitions were in place when I brought up
the DR TSM it would have had access to the library and volumes in the
library
- the recycle of the DR TSM is neccessay after the PROD TSM is down and
before bringing up the DR TSM to replace the addressing so that it
matches the previous addressing on the PROD TSM ( 1Z-08-02 becomes
1Z-08-01)

Any thoughts or experience with the use of a library in this
situation?




I tried this because I noticed that with both servers connected to the
switch that distinct addresses are generated for each set of devices. So
restoring the prod TSM DB and bringing it up it appears to see these
devices on the DR TSM server as not the same as the devices it used when
it was the DB was saved off.

However, having the prod TSM server down and recycling DR TSM server
prior to starting TSM on the DR server restablishes the addresses on
server so they are the primary addresses ( 01) and allows the library
and devices to be recognized and defined. At least that's my theory. The
limited testing I was able to do suggests that it true.


[tsmserv] /home/root # lsdev -Cc tape
lmcp0 Available          LAN/TTY Library Management Control Point
lmcp1 Available          LAN/TTY Library Management Control Point
rmt0  Available 1H-08-01 IBM 3590 Tape Drive and Medium Changer (FCP)
rmt1  Available 1H-08-01 IBM 3590 Tape Drive and Medium Changer (FCP)
rmt2  Available 1Z-08-01 IBM 3590 Tape Drive and Medium Changer (FCP)
rmt3  Available 1Z-08-01 IBM 3590 Tape Drive and Medium Changer (FCP)
rmt4  Available 1Z-08-01 IBM 3590 Tape Drive and Medium Changer (FCP)
rmt5  Available 1Z-08-01 IBM 3590 Tape Drive and Medium Changer (FCP)

[tsmserv2] /home/root # lsdev -Cc tape
lmcp0 Available          LAN/TTY Library Management Control Point
lmcp1 Available          LAN/TTY Library Management Control Point
rmt2  Available 1Z-08-02 IBM 3590 Tape Drive and Medium Changer (FCP)
rmt3  Available 1Z-08-02 IBM 3590 Tape Drive and Medium Changer (FCP)
rmt4  Available 1Z-08-02 IBM 3590 Tape Drive and Medium Changer (FCP)
rmt5  Available 1Z-08-02 IBM 3590 Tape Drive and Medium Changer (FCP)

<Prev in Thread] Current Thread [Next in Thread>
  • Accessing 3494 library in DR senario, Lawrence Clark <=