STANLEY R. HORWITZ wrote:
On 02 25, 2010, at 10:19 AM, George Sinclair wrote:
STANLEY R. HORWITZ wrote:
On 02 24, 2010, at 8:58 PM, George Sinclair wrote:
Hi,
We have a new test server operating under 30 day eval. Getting ready to
put this into production soon. Still testing. We will be recovering the
media database and resource database from our older current server (DR
recover) in order to test some recoveries of older data and to run some
queries against the media database to verify that it looks the same as
on the older server.
The old server is still handling nightly backups until the testing has
been completed on the new machine, however. Both servers have different
host names, but the same client id (I made sure of that).
I'm concerned about the possibility that both servers could get shut
down when the test server sees that it now has licenses assigned to the
old server (as a result of recovering the old server's resource
database). But I don't want to have to recreate all the NSR resources
from scratch, though, and I don't really want to have to shut down the
old server during our tests.
Questions:
1. Do we have to do the host transfer/affidavit immediately and get new
keys even though we're not ready to go live just yet?
2. Can I avoid the license conflict issue by removing all the files on
the new test server under /nsr/res/nsrdb that contain any enabler codes
from the old server?
Just contact your EMC account manager to request whatever temporary license
enablers you need for the test server.
I'm still unclear on how that will resolve the fact that when we run the
DR recover, we'll still have the old server's res database recovered as
res.R. When we rename that to res, we'll still have the old server's
licenses in there. We then add the new enablers, but it might be too
late? I do want to recover the old server's res so I don't have to
recreate all the resources from scratch.
Alternatively, if we add the temporary enablers before the DR, then
they'll be under the current res directory, not res.R, so we won't have
them when we do the rename, and then we're back in the same boat?
You shut down your production server. On the DR server, do your mmrecov using
the production server's most recent bootstrap information. Bring up the DR
server as per the mmrecov directions, then put in the evaluation license
enabler using nsrcap. Once you do that, double check on the DR server that the
new evaluation enabler is in place. Assuming the evaluation license enabler is
in place, you can bring up your production NetWorker server. If you really want
to be sure the two servers will play nicely, put your DR server on a private
network where it cannot ping your production server and vise versa, and then
open up the private network to whatever clients you intend to do restore
testing on.
Thanks, Stan! A few more questions:
1. When you say 'evaluation license enabler', I assume you mean a 45-day
temporary one that we would get from EMC, correct?
2. Do we also need to add separate enablers for everything else (e.g.
autochanger, client connections, etc.) , or can we get just one 45-day
enabler code for the whole thing?
In other words, it's always been my understanding that you either have
something like 'NetWorker/10 Eval' with 'Enabler code: none', and that
lasts for 30 days, giving you carte blanche to everything, or you have
separate codes for each item you need licensed.
3. Why do we need to use nsrcap to do this? Couldn't we just us nmc and
add it there?
4. According to the man page for nsrcap, nsrd must be running. Should we
*only* start up nsrd, then run nsrcap, add the license, then stop nsrd
and then restart the whole server as normal? Or should we instead start
the whole thing as usual, from the get go, and then run nsrcap and add?
5. Should nsrcap be run with '-c' or '-u' option?
6. Following on question 4. after our mmrecov operation, we will have
recovered both the old media database and resource database. We have to
rename res.R to res before starting the DR server (I would probably make
copies of mm and res before doing the DR). At that point, we will have
the old server's license keys in there. I'm still unclear on how running
nsrcap at that point, and adding the new eval enabler, will get around
the problem that the server will have those older keys that it could
broadcast. Even if the old server is down during this time, and we add
the new enabler to the new test server, won't the test server still
continue to broadcast those older licenses? Maybe it's moot once it has
the new enabler?
We are not able to set up a private network at this time, so should we
remove the files under /nsr/res/nsrdb that contain those old keys before
starting the test server or running nsrd or nsrcap or will adding the
new enabler make all that moot?
Thanks!
George
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
--
George Sinclair
Voice: (301) 713-3284 x210
- The preceding message is personal and does not reflect any official or
unofficial position of the United States Department of Commerce -
- Any opinions expressed in this message are NOT those of the US Govt. -
To sign off this list, send email to listserv AT listserv.temple DOT edu and type
"signoff networker" in the body of the email. Please write to networker-request
AT listserv.temple DOT edu if you have any problems with this list. You can access the
archives at http://listserv.temple.edu/archives/networker.html or
via RSS at http://listserv.temple.edu/cgi-bin/wa?RSS&L=NETWORKER
|
