[OpenAFS] Moving Authen Servers to different IP addresses

[Russ Allbery]

Greg Wilson <Greg.Wilson@asu.edu> writes:

> Here at ASU we currently have the 3 defined authen servers know by our
> AFS clients all in one network subnet.

> We have a need to be able to split these up to several different network
> locations.

> What are the ramifications for this and how can this be done?

First, if you haven't already, set up AFSDB and SRV records for your cell
in DNS and change your deployment and configuration practices so that all
new systems use -afsdb as an option to afsd.  You may even want to
consider not deploying a CellServDB file at all.  That will make future
changes of this sort much easier.

The basic problem is that you need a new CellServDB on all clients (or
turn it off and use AFSDB/SRV only).  Clients will cope with some of the
VLDB servers going away from the client perspective *as long as* the Ubik
master is one of the ones that doesn't go a way.

You have two main strategies.  Strategy one:

1. Add new VLDB servers to your cell by updating the server-side
   CellServDB in your existing VLDB servers and file servers.
2. Update CellServDB on all clients to reference the new ones instead of
   the old ones (or disable CellServDB and use only DNS).
3. Retire the old ones once there aren't any clients talking to them.

You'll also need to coordinate an update of the world-wide CellServDB file
if you have clients that get the CellServDB from stock packages instead of
local configuration.

Strategy two (faster but riskier):

1. Start updating CellServDB on all clients ASAP.
2. Move the high-IP VLDB servers to new IP addresses and update the
   server CellServDB files on file servers and VLDB servers.

Clients that don't have an updated file will cope as long as the master
doesn't change, although there will be slowness as they time out on the
VLDB servers that aren't there any more.

Note that updating CellServDB requires a reboot to re-read it, but you can
change the running cache manager server list with the fs newcell command.
So you can do this without rebooting clients, although rebooting clients
is best so that you can be sure the startup behavior is correct (anything
you do with fs newcell will vanish on reboot).

We did this a long time ago using strategy one.  It took a while, but it
wasn't too bad.

-- 
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>