[548] in Info-AFS_Redistribution
Re: Changing DB server IP addresses
daemon@ATHENA.MIT.EDU (Gunnar Lindberg)
Mon Jan 20 15:17:40 1992
Date: Mon, 20 Jan 92 19:56:40 +0100
From: Gunnar Lindberg <lindberg@cs.chalmers.se>
To: Info-AFS@transarc.com
Cc: bernerus@cs.chalmers.se, tafvelin@ce.chalmers.se, torbjar@utc.chalmers.se
>From: Christer Bernerus <bernerus@cs.chalmers.se>
>
>Excerpts from info-afs: 16-Jan-92 Changing DB server IP addre.. John
>Gardiner Myers@andr (549)
>> I believe the most correct solution is to never change the IP
>> addresses of your DB servers once you've advertised their existence.
>If I told my Network managers that, they'd tell me that the correct
>solution would be NOT using AFS at all !
> That's the approach we take here.
>And that's probably why things are the way they are !
Since I'm not on this mailing list (and I don't think I should be)
I've of course missed the start of the discussion. Being one of the
NetWorkers that <bernerus> refer to above, however, I'll hand in a
few comments:
In an active and "living" technical environment, like
computers using networking, you can never hope to predict
more future development than 1-2 years ahead;
Ethernet => FDDI => Gbit/s => God_Knows,_But_It'll_Be_Fast.
Add to this the "geographical dynamics" of a university, i.e.
research groups that move, split and re-combine, fighting
about "my equipment", "your equipment" and "I bought that!".
Also remember the Academical Freedom: "my research group
must not have its work restricted by anyone..." etc, etc.
Do researchers tell what they'll use their hosts for?
Now, combine these (and other similar things that you can
imagine yourself :-) with the fairly inflexible scheme of
IP addressing: Subnets and Hosts, on power_of_2 boundaries.
Anyone to suggest a reasonable "netmask"?
Of course, a real Guru would have known beforehand which hosts were
to become AFS servers and would have allocated addresses on reasonable
subnet boundaries for each of them (reasonable not only as of today,
but for the next 10 years). Unfortunately Chalmers University didn't
hire Gurus for this...
Bad luck!
We've performed an almost complete renumbering of Chalmers' IP hosts
by now. The experiences to date are that although it's quite some
work for sysmgr:s, it's actually possible to minimize the overall
pain by careful use of DNS facilities (short cache TTL:s and MX:s
that reference the old addresses as well as the new ones); nothing
especially "magic", but straight ahead engineering work. To what
extent people outside Chalmers have had severe problems due to our
renumbering I don't know, but since we've had email operational all
the time (yes, I know for sure we have! :-) I guess at least some
complaints should have reached here...
Now, AFS ("worldwide AFS"?) seems to be quite another story. Where
DNS allowed us to control the TTL of an address and made it possible
for us to "fade out" the old ones, it seems like a number of AFS
hosts keep their private cache and still try to reference addresses
that disappeared more than two months ago...
So, what's the alternative?
To me, the ">>" statement above just doesn't make sense; the kind
of organization that can fulfill such a requirement simply doesn't
exist! Instead you'll have to build tools to make changes take place
with as little pain and effort as possible. Since I assume AFS is
intended to operate in a large world wide environment (expected to
be quite dynamic!) the need for good management tools will increase
rather than decrease. One possibility, if you really need to use an
IP address cache, would be to make it use TTL:s based on those used
by DNS (included in DNS messages, RFC1035) and refresh using DNS.
Gunnar Lindberg, NetWorker, Chalmers
