Subject: RE: Configuration Management

From: Bernie Volz <[email-masked]>
Date: Sun, 19 Dec 1999 12:13:17 -0400

The failover draft does imply that both servers have generally the
same configuration. The major items that must agree are the lease pools.
Options sent to clients (such as lease times, etc) could be different
(though clients may thus get different information depending on which
server replies).

For our offering, when an administrator says to apply an updated
configuration via the UI, we trigger both servers to use the new
configuration. It is possible though that one server may not get the
notification (if the network is partitioned, etc).

The protocol needs to be robust enough to handle different
configurations - this may cause a binding update to be rejected because
it is not in one server's pool. Or, the secondary may not be assigned
any addresses for a pool that the primary knows nothing about.

Perhaps we should consider some mechanism for one server to tell the
other that it suspects a misconfiguration. However, how to "recover"
from that (since which server is out of date is not easy to detemrine)
is a good question. I guess one could assume that each server might take
steps to check if the configuration it has is current and use any
updated configuration if not.

Sending over or negotiating configuration information would be a huge
and difficult task as no two server implementations have all of the same
configuration parameters. Limiting this exchange to lease pools might be
reasonable, but again how do you know which server has the correct data?
All you could determine is that the data doesn't match.

The parameters that are critical for making the failover protocol work
(such as agreement on the MCLT) are exchanged (primary's values used).

- Bernie Volz
  Process Software

Date: Thu, 9 Dec 1999 19:03:31 -0500 (EST)
Message-ID: <716D440F8C29D311991100A0C920487423D973@GIDGET>
From: "Kostur, Andre" <[email-masked]>
To: Multiple recipients of list <[email-masked]>
Subject: Configuration Management

I'm curious as to how the rest of the implementors are approaching the
problem of configuration management between the primary and secondary
servers.  As far as I can tell, the draft just says (implies?) that the two
servers are configured identically, and that's that.  However one must still
deal with the problem.  Does a configuration change mean that both servers
have to be effectively stopped, apply the configuration change, then restart
the services?  Or do the two servers talk to each other about config changes
when they happen?  And in this case, what if there are config changes during
COMMUNICATIONS-INTERRUPTED or PARTNER-DOWN states (ok, basically any state
other than NORMAL....)?

---

From: Kim Kinnear <[email-masked]>
Date: Mon, 20 Dec 1999 10:32:38 -0500

Andre, 

I agree completely with Bernie on this.  
I have a couple of comments which I placed in-line, below.

Cheers -- Kim

>any addresses for a pool that the primary knows nothing about.

         Yes, this is the key point.  The protocol has to keep
         operating in the face of unsynchronized configuration
         changes between partners.  Although you can always stop
         them from communicating, make the config changes, and
         then restart the communications.  We have not had to do
         that with our implementation, and have had no problems
         traceable to any configuration changes.

>other that it suspects a misconfiguration. 

         To some (very small) degree we do have this: one of the
         NAK reply codes is "Illegal IP address", which is
         designed to highlight an IP address not part of any pool
         on the receiving server.  If a message is received with
         an IP address that a server doesn't know about,
         presumably it is a configuration error -- since the
         sending server shouldn't have sent it if it didn't think
         the receiving server was going to be able to respond to
         it.

>However, how to "recover"

         I tried this in an early "interserver" draft, and it was
         one (among, unfortunately, several) reason why that draft
         more or less fell over under its own weight.  There is a
         very strong Working Group belief that including
         configuration information in the failover protocol is a
         bad idea, no doubt partly as a result of this early attempt
         at doing so.