Joe's right though. The safest (and easiest) way to do this is to bring up
the new servers, make sure they're working, and then kill the old ones.
As look as all of the clients can see (have routes to/from) both the ATM
and ethernet networks, it shouldn't matter how many hops there are between
them.
Strictly speaking, you can bring down any number of the servers you have
now, and move them, and then fix all of the clients' CellServDB files. It
should work, but I wouldn't recommend it, and I doubt very many people
would. It would result in an extended downtime for the entire cell, and
there are the always present risks that something will go wrong.
In my experience, the best way is this:
1) Bring up new servers
2) Add new servers to clients' CellServDB
3) Wait a few days (I have bad luck)
4) Kill the old servers
5) Update clients' CellServDB files
This results in minimal cell outage. There is a small downtime
(seconds/minutes) when you add the new servers, because you have to
(should) restart all of the DB processes so that the servers can
re-negotiate the sync site. Then you have another small downtime (minutes)
when you restart them again after killing the old ones. You also see some
timeouts on the client side at that point, but it's not usually too
invasive.
I don't know what your routing issues are, but as long as the IP traffic
can get from point A to point B, it shouldn't be a problem. Many cells
have DB servers separated by WAN links.
I also have to say that this works best when the new servers having higher
IPs than the current sync site. If your new network is a lower address
than the old one, you pretty much have to move a server. Luckily, I've
never had to do this, my servers have always moved to higher networks.
Nathan
On Fri, 10 Jul 1998, Norman P. B. Joseph wrote:
> On Jul 10, 13:24 Joe Ramus ([EMAIL PROTECTED]) wrote:
>
> > Do you have new hardware for the servers?
> > If so, I would keep the old servers in place and add the three new
> > servers. Change the CellServDB file on all clients.
> > Remove the old Servers.
>
> Ah, there's the rub, and the reason I need to migrate to the new IP addresses.
> The original servers all use ATM interfaces to talk to each other and to their
> clients, the new servers will have only Ethernet. I don't have the ability to
> route between the Ethernet and ATM subnets directly. My only option seems to
> be to implement LAN Emulation on my server's ATM interfaces, so they can be
> routed, so that I can then add the non-ATM database servers. This involves
> giving them new IP addresses. It actually gets more complicated than this,
> but, again, I don't want to cloud things up unneccessarily.
>
> Thanks,
> --
> ~ ~
> Norman Joseph, Systems Administrator [EMAIL PROTECTED] IC|XC
> Concurrent Technologies Corporation 814/269.2633 --+--
> NI|KA
>
