[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
first.
/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
run
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