[OpenAFS] vos listaddrs/changeaddr problems with old multihomed host
Sven Oehme
oehmes@de.ibm.com
Sun, 12 Dec 2004 10:20:53 +0100
This is a multipart message in MIME format.
--=_alternative 003348F2C1256F68_=
Content-Type: text/plain; charset="US-ASCII"
Hi Jeffrey,
we had the same problem in multihomed environments if we forgot to
configure the NetRestrict NetInfo files before starting the server. i used
that procedure several times .. on modern hardware it takes less than 5
sec to finish. i wouldn't name that really outage and no user every
complained about it.
May be there are smarter ways to do so, but it fixes the Problem for me
and it's very quick.
I agree that if the NetInfo NetRestict isn't configured correctly and the
ip still exists on the Server this wouldn't fix the Problem in long terms,
but after he fixed his configuration, my procedure would clean his volume
still exists problem ...
Sven
-------------------------------------------------------------------------------------------------------------------------
Dept. A141, TG/SSG EMEA AIS Strategy and Architecture
Development Leader Stonehenge
IBM intranet ---> http://w3.ais.mainz.de.ibm.com/stonehenge/
internet ---> http://www-5.ibm.com/services/de/its/filestore.html
Phone (+49)-6131-84-3151
Fax (+49)-6131-84-6708
Mobil (+49)-171-970-6664
E-Mail : oehmes@de.ibm.com
openafs-info-admin@openafs.org wrote on 12/12/2004 01:16:30:
> On Saturday, December 11, 2004 03:00:16 -0500 Kenneth J Baker
> <bakerkj@umich.edu> wrote:
>
> > If I try to remove either of them I get the following error:
>
> You don't want to do that. What you're asking the vlserver to do is to
> remove the entire server, which it can't do because it knows about
volumes
> on that server -- and which isn't what you want anyway.
>
> What you need to do is to get the fileserver to register the correct set
of
> addresses. The fileserver registers its addresses on startup, based on
the
> interfaces present and the contents of the NetInfo and NetRestrict
files.
>
> If you want the 172.17 addresses to go away, you need to either make
those
> interfaces go away (configuring them down may not be enough), or add
those
> addresses to the NetRestrict files on the fileservers.
>
> > I investigated and it appears that the file servers themselves are
using
> > only the correct interface: Sat Dec 11 02:37:00 2004 Getting
FileServer
> > name...
> > Sat Dec 11 02:37:00 2004 FileServer host name is 'deedee'
> > Sat Dec 11 02:37:00 2004 Getting FileServer address...
> > Sat Dec 11 02:37:00 2004 FileServer deedee has address 66.92.68.189
> > (0xbd445c42 or 0x425c44bd in host byte order) Sat Dec 11 02:37:00 2004
> > File Server started Sat Dec 11 02:37:00 2004 ** **
> > Sat Dec 11 01:51:19 2004 Getting FileServer name...
> > Sat Dec 11 01:51:19 2004 FileServer host name is 'dharma'
> > Sat Dec 11 01:51:19 2004 Getting FileServer address...
> > Sat Dec 11 01:51:19 2004 FileServer dharma has address 66.205.64.240
> > (0xf040cd42 or 0x42cd40f0 in host byte order) Sat Dec 11 01:51:19 2004
> > File Server started Sat Dec 11 01:51:19 2004
>
> No; that's not what that means. The "Fileserver... has address" message
> tells you what the fileserver's primary address is; it does not indicate
> that no other addresses have been registered with the VLDB.
>
>
> Sven Oehme wrote:
> > just do the following per server :
> >
> > vos delentry -server 172.17.193.x
> > vos syncvldb servername
> > vos syncserv servername
> >
> > now the vos changeaddr 172.17.193.2 -remove -local should work ...
>
> No, don't do that. Not only will it result in a service outage during
the
> time when you remove every volume on that server from the VLDB and the
time
> when vos syncvldb puts them back, it also won't make your problem go
away.
> As the output from 'vos listaddrs -printuuid' indicates, each server has
> both addresses. Removing and re-adding the volumes won't change the set
of
> addresses associated with the server, and won't split the one server
into
> two.
>
>
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
> Sr. Research Systems Programmer
> School of Computer Science - Research Computing Facility
> Carnegie Mellon University - Pittsburgh, PA
>
>
>
>
> _______________________________________________
> OpenAFS-info mailing list
> OpenAFS-info@openafs.org
> https://lists.openafs.org/mailman/listinfo/openafs-info
--=_alternative 003348F2C1256F68_=
Content-Type: text/html; charset="US-ASCII"
<br><font size=2 face="sans-serif">Hi Jeffrey,</font>
<br>
<br><font size=2 face="sans-serif">we had the same problem in multihomed
environments if we forgot to configure the NetRestrict NetInfo files before
starting the server. i used that procedure several times .. on modern hardware
it takes less than 5 sec to finish. i wouldn't name that really outage
and no user every complained about it.</font>
<br>
<br><font size=2 face="sans-serif">May be there are smarter ways to do
so, but it fixes the Problem for me and it's very quick.</font>
<br>
<br><font size=2 face="sans-serif">I agree that if the NetInfo NetRestict
isn't configured correctly and the ip still exists on the Server this wouldn't
fix the Problem in long terms, but after he fixed his configuration, my
procedure would clean his volume still exists problem ...</font>
<br>
<br><font size=2 face="sans-serif">Sven<br>
-------------------------------------------------------------------------------------------------------------------------<br>
Dept. A141, TG/SSG EMEA AIS Strategy and Architecture<br>
Development Leader Stonehenge <br>
IBM intranet ---> http://w3.ais.mainz.de.ibm.com/stonehenge/<br>
internet ---> http://www-5.ibm.com/services/de/its/filestore.html<br>
Phone (+49)-6131-84-3151<br>
Fax (+49)-6131-84-6708<br>
Mobil (+49)-171-970-6664<br>
E-Mail : oehmes@de.ibm.com</font>
<br>
<br><font size=2><tt>openafs-info-admin@openafs.org wrote on 12/12/2004
01:16:30:<br>
<br>
> On Saturday, December 11, 2004 03:00:16 -0500 Kenneth J Baker <br>
> <bakerkj@umich.edu> wrote:<br>
> <br>
> > If I try to remove either of them I get the following error:<br>
> <br>
> You don't want to do that. What you're asking the vlserver to
do is to <br>
> remove the entire server, which it can't do because it knows about
volumes <br>
> on that server -- and which isn't what you want anyway.<br>
> <br>
> What you need to do is to get the fileserver to register the correct
set of <br>
> addresses. The fileserver registers its addresses on startup,
based on the <br>
> interfaces present and the contents of the NetInfo and NetRestrict
files.<br>
> <br>
> If you want the 172.17 addresses to go away, you need to either make
those <br>
> interfaces go away (configuring them down may not be enough), or add
those <br>
> addresses to the NetRestrict files on the fileservers.<br>
> <br>
> > I investigated and it appears that the file servers themselves
are using<br>
> > only the correct interface: Sat Dec 11 02:37:00 2004 Getting
FileServer<br>
> > name...<br>
> > Sat Dec 11 02:37:00 2004 FileServer host name is 'deedee'<br>
> > Sat Dec 11 02:37:00 2004 Getting FileServer address...<br>
> > Sat Dec 11 02:37:00 2004 FileServer deedee has address 66.92.68.189<br>
> > (0xbd445c42 or 0x425c44bd in host byte order) Sat Dec 11 02:37:00
2004<br>
> > File Server started Sat Dec 11 02:37:00 2004 ** **<br>
> > Sat Dec 11 01:51:19 2004 Getting FileServer name...<br>
> > Sat Dec 11 01:51:19 2004 FileServer host name is 'dharma'<br>
> > Sat Dec 11 01:51:19 2004 Getting FileServer address...<br>
> > Sat Dec 11 01:51:19 2004 FileServer dharma has address 66.205.64.240<br>
> > (0xf040cd42 or 0x42cd40f0 in host byte order) Sat Dec 11 01:51:19
2004<br>
> > File Server started Sat Dec 11 01:51:19 2004<br>
> <br>
> No; that's not what that means. The "Fileserver... has
address" message <br>
> tells you what the fileserver's primary address is; it does not indicate
<br>
> that no other addresses have been registered with the VLDB.<br>
> <br>
> <br>
> Sven Oehme wrote:<br>
> > just do the following per server :<br>
> ><br>
> > vos delentry -server 172.17.193.x<br>
> > vos syncvldb servername<br>
> > vos syncserv servername<br>
> ><br>
> > now the vos changeaddr 172.17.193.2 -remove -local should work
...<br>
> <br>
> No, don't do that. Not only will it result in a service outage
during the <br>
> time when you remove every volume on that server from the VLDB and
the time <br>
> when vos syncvldb puts them back, it also won't make your problem
go away. <br>
> As the output from 'vos listaddrs -printuuid' indicates, each server
has <br>
> both addresses. Removing and re-adding the volumes won't change
the set of <br>
> addresses associated with the server, and won't split the one server
into <br>
> two.<br>
> <br>
> <br>
> -- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu><br>
> Sr. Research Systems Programmer<br>
> School of Computer Science - Research Computing Facility<br>
> Carnegie Mellon University - Pittsburgh, PA<br>
> <br>
> <br>
> <br>
> <br>
> _______________________________________________<br>
> OpenAFS-info mailing list<br>
> OpenAFS-info@openafs.org<br>
> https://lists.openafs.org/mailman/listinfo/openafs-info<br>
</tt></font>
--=_alternative 003348F2C1256F68_=--