Novell Home

BorderManager Migration Tips

Novell Cool Solutions: Tip
By Craig Johnson

Digg This - Slashdot This

Posted: 17 Oct 2007
 

Problem

A Forum reader recently asked:

"We are currently running NBM 3.8 SP5 on a seven-year-old P3 666Mhz server that needs to be upgraded. We have new hardware, but I need advice on the best way to migrate. I would like to keep the same server name and IP address and same location in the eDirectory tree. We plan on an upgrade to NBM 3.9 as long as we are at it.

Should I run the migration wizard to move NetWare, or am I better off just installing a clean copy and then changing the name and IP address once I put it into production?

Can you point me to instructions on how to copy the packet filter database from 3.8 to 3.9? I'm assuming I'll do a clean copy of NBM 3.9 once I get NetWare going."

And here's the response from Craig Johnson ...

Solution

My preference is to not hang on to what you have mentioned above. If you have one more public IP address, here is my preferred migration strategy (also detailed in my BorderManager 3.x book):

1. Make a new OU for another BorderManager server. You don't have to do this, but I think it makes things easier to manage later, in terms of filtering issues and license issues. Partition off the new OU.

2. Install a new server in the new OU. Put a replica of the OU on it and make it master.

3. Install BMgr on the new server. Disable RIP on both servers.

4. Get everything set up on the new server and working, in parallel with the old one. You can copy access rules and filters over if you know what you are doing, or you can just recreate all manually.

5. When you are confident the new server is ready, swing the old server's private IP address to the new server, as a secondary IP address. Add it as a private proxy address for the proxy to listen on. At this time, the old server should have a different private IP address, or be turned off. (I like to leave it up on a different address, so as to be able to switch back to it if something goes wrong on the new server).

6. If all is well, you can take the old server out of the tree and turn it off. In some cases it is worth reusing the old server by upgrading it in place, and then making it part of a two-node cluster with the new server. It's nice to have a backup node for your Internet connection.

If you know what you are doing, you can also use an across-the-wire migration strategy. However, you still have to install NetWare, and you'll still have to do a lot of little manual steps.

If you do the parallel server approach, it takes the pressure off, because the old server is still running until you have the new one working. Otherwise, you may be in a situation with the Internet down, on a Sunday night, scrambling to get every little thing working as before, and hoping it gets done by Monday morning.

I cover filtering issues in my BMgr filtering book - see the URL above. Depending on how you migrate, you either copy things over and do a filtsrv migrate, or you may have filters migrated for you. But there is a lot of 'devil in the details' on this, such as being sure your interface names match between the old and new servers.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell