[OpenAFS] Offlining of Database server

Marcus Watts mdw@spam.ifs.umich.edu
Wed, 27 Jun 2007 16:04:23 -0400

> Date:    Wed, 27 Jun 2007 10:19:05 EDT
> To:      <openafs-info@openafs.org>
> From:    "David Sonenberg" <dsonenberg@strozllc.com>
> Subject: [OpenAFS] Offlining of Database server
> So I have migrated all but a few problematic volumes to a new server.  I
> have a number of bogus volumes with replicas on other sites, that I
> can't delete with 'vos remsite' and 'vos delete.'  Additionally I have a
> few readonly volumes located on that server that have no readwrite pair,
> but I can't delete them either.  My question is how do I get rid of
> these problematic volumes?  Then once I do what do I need to do to
> decommission the server?  This was our first AFS server, it has the
> lowest IP, and is running all the database servers as well as the
> fileserver.
> --
> David Sonenberg, CISSP, GCIH, CCNA

If there is no AFS volume data you value on that machine, then:
on that machine,
bos shutdown localhost fs -localauth
umount /vicepa		<-- or whatever
newfs /dev/XXX		<-- however it was mounted, mkfs on linux

Now you have a simple database server with some empty disk
space.  You can bring it back up as a fileserver if you want,
or you can just leave it if you don't care.  You might want
to do "vos changeaddr" if you don't intend to offer fileservice
on this machine again.

If you want to eliminate this machine entirely (ie not have it
as a database server) [which you should NOT do unless you REALLY
want to do this] - then you need something like these steps:

/0/ - since you're retiring fs serivce on your host,
	vos listvldb -server <oldhost>
	vos delentry XXX
		if you had rw volumes on your old host
		(since you just did a newfs, the volume isn't there.)
	vos remsite
		you shouldn't need this, but in case you do
	vos changeaddr <oldhost> -remove
		make ipaddr go away for good.  Won't succeed
		if there are any references to oldhost,
		which is why you need to do listvldb/delentry/remsite
/1/ *all* your client machines, and any other client machines
that know about your cell,
	edit CellServDB
	remove the machine.
/2/ "bos removehost" on your server machines - or edit
	/etc/openafs/server/CellServDB directly.
/3/ stop db services on your old host
	wait for the remaining db hosts to agree on a new
	sync site.  (use udebug to detect when.)
/4/ stop & restart db services on remaining hosts, with delay
	between each host.  (restart is so they pick up the
	new cellservdb, delay is so that you don't break
	voting more than necessary.)
If you only have 2 db hosts, you can do 2-3-4 with no delays,
and you will end up with 1 db host.

It is best practice, given a sufficient sized environment, to
	3 db hosts that do little or no file service
		should well connnected, could be distributed.
	N fs hosts that only provide file service

Normally, instead of just retiring a db host, you would replace it
with a new machine at the same IP address.  Typically you would use
newer faster hardware.

For file servers, typically you upgrade them by moving everything off,
replacing with new hardware, and if possible, copy the old sysid file
onto the new hardware.  If you don't intend to immediately reuse
the ip address, you should do "vos changeaddr" and then don't
bother preserving sysid.

				-Marcus Watts