[OpenAFS] Offlining of Database server

[David Sonenberg]

I do want to retire the old server entirely but I could change the new
server's IP address to be the same as the old one.  If I was going to do
this what would the procedure be?=20


--
David Sonenberg, CISSP, GCIH, CCNA
Director, Information Technology
Stroz Friedberg, LLC
http://www.strozllc.com
15 Maiden Lane
12th Floor
New York, NY 10038
Tel 212.981.6527
Fax 212.981.6545
-----Original Message-----
From: Marcus Watts [mailto:mdw@spam.ifs.umich.edu]=20
Sent: Wednesday, June 27, 2007 4:04 PM
To: David Sonenberg
Cc: openafs-info@openafs.org
Subject: Re: [OpenAFS] Offlining of Database server

> 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
>=20
> 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=20=

> can't delete with 'vos remsite' and 'vos delete.'  Additionally I have

> a few readonly volumes located on that server that have no readwrite=20=

> 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=20=

> decommission the server?  This was our first AFS server, it has the=20
> lowest IP, and is running all the database servers as well as the=20
> fileserver.
>=20
> --
> David Sonenberg, CISSP, GCIH, CCNA
=2E..

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




This message is for the named person's use only.  It may contain
confidential, proprietary or legally privileged information. No right
to confidential or privileged treatment of this message is waived or
lost by any error in transmission.  If you have received this message
in error, please immediately notify the sender by e-mail or by
telephone, delete the message and all copies from your system and
destroy any hard copies.  You must not, directly or indirectly, use,
disclose, distribute, print or copy any part of this message if you
are not the intended recipient.