[OpenAFS] Moving Authen Servers to different IP addresses

[Greg Wilson]

Thanks Russ for your response.=0A=
=0A=
Any thoughts on the final physical location of the 3 servers and network ba=
ndwith between them?=0A=
=0A=
Is it better to have them in 3 different physical locations with 3 differen=
t IP's and if so what should be the bandwith between them.=0A=
=0A=
I notice in the global CellServDB file that may AFS db servers for differen=
t installations are all in the same subnet.=0A=
=0A=
Greg=0A=
=0A=
=0A=
________________________________________=0A=
From: Russ Allbery [rra@stanford.edu]=0A=
Sent: Monday, April 22, 2013 11:56 AM=0A=
To: Greg Wilson=0A=
Cc: openafs-info@openafs.org=0A=
Subject: Re: [OpenAFS] Moving Authen Servers to different IP addresses=0A=
=0A=
Greg Wilson <Greg.Wilson@asu.edu> writes:=0A=
=0A=
> Here at ASU we currently have the 3 defined authen servers know by our=0A=
> AFS clients all in one network subnet.=0A=
=0A=
> We have a need to be able to split these up to several different network=
=0A=
> locations.=0A=
=0A=
> What are the ramifications for this and how can this be done?=0A=
=0A=
First, if you haven't already, set up AFSDB and SRV records for your cell=
=0A=
in DNS and change your deployment and configuration practices so that all=
=0A=
new systems use -afsdb as an option to afsd.  You may even want to=0A=
consider not deploying a CellServDB file at all.  That will make future=0A=
changes of this sort much easier.=0A=
=0A=
The basic problem is that you need a new CellServDB on all clients (or=0A=
turn it off and use AFSDB/SRV only).  Clients will cope with some of the=0A=
VLDB servers going away from the client perspective *as long as* the Ubik=
=0A=
master is one of the ones that doesn't go a way.=0A=
=0A=
You have two main strategies.  Strategy one:=0A=
=0A=
1. Add new VLDB servers to your cell by updating the server-side=0A=
   CellServDB in your existing VLDB servers and file servers.=0A=
2. Update CellServDB on all clients to reference the new ones instead of=0A=
   the old ones (or disable CellServDB and use only DNS).=0A=
3. Retire the old ones once there aren't any clients talking to them.=0A=
=0A=
You'll also need to coordinate an update of the world-wide CellServDB file=
=0A=
if you have clients that get the CellServDB from stock packages instead of=
=0A=
local configuration.=0A=
=0A=
Strategy two (faster but riskier):=0A=
=0A=
1. Start updating CellServDB on all clients ASAP.=0A=
2. Move the high-IP VLDB servers to new IP addresses and update the=0A=
   server CellServDB files on file servers and VLDB servers.=0A=
=0A=
Clients that don't have an updated file will cope as long as the master=0A=
doesn't change, although there will be slowness as they time out on the=0A=
VLDB servers that aren't there any more.=0A=
=0A=
Note that updating CellServDB requires a reboot to re-read it, but you can=
=0A=
change the running cache manager server list with the fs newcell command.=
=0A=
So you can do this without rebooting clients, although rebooting clients=0A=
is best so that you can be sure the startup behavior is correct (anything=
=0A=
you do with fs newcell will vanish on reboot).=0A=
=0A=
We did this a long time ago using strategy one.  It took a while, but it=0A=
wasn't too bad.=0A=
=0A=
--=0A=
Russ Allbery (rra@stanford.edu)             <http://www.eyrie.org/~eagle/>=
=0A=