Re: [9fans] DHCP

[<plan9@itic.ca>]

----- Original Message -----
From: <presotto@plan9.bell-labs.com>

> I'm about to replace the current file system based state sharing in
> dhcpd with the one from the internet draft:
>
>   "DHCP Failover Protocol", Ralph Droms, Bernard Volz, K. Kinnear, Arun
>   Kapur, Mark Stapp, Greg Rabil, Mike Dooley, Steve Gonczi, 01/24/2002,
>   <draft-ietf-dhc-failover-10.txt>
>
> The current dhcpd addresses the case of a single cpu falling over, but
> has a single point of failure if we lose the shared file server all
> the servers are running from.
>

We have considered those solutions :
    Running dhcpd on the file server itself      [does not resolve a single
point of failure situation]
    Running dhcpd on a special pccpudisk    [the kfs has /lib/ndb/... and it
serves security files too]
The last one was ok, provided this CPU and its backups do not reboot upon fs
connectivity failure...

> The IETF draft separates the address space so that each server only serves
> from its own pool of addresses but updates the others' state through
> a special protocol so that each can take over should its partner fail.
> I'm a bit bothered that it only supports 2 servers but maybe I'm
> being silly.
>

In normal IP world, 2 dhcpd instances are normal. In a Plan 9 architecture
it could be interesting to get *any* CPU offering dhcp if they all share the
same coherent adress space and serve only when needed. The problem becomes
the way to `share' coherent state informations over the network. The closest
and *simplest* protocol could be something like a [L2 only] Cisco Discovery
Protocol that also propagates node functionnality informations. The Plan 9
Discovery Protocol could implement a service state message semaphore that
serves informations in sothing � la  /dev/env  I see this more in terms of
conventions, since protocol versioning and new services are not predictable.

> Another possible solution would be to use the current dhcpd but run it
> on top of either
> (1) a very reliable file server (venti?)
> or

I am not sure it is a good idea to use an essential and booting phase
service on the top of something complex relying on other services within an
architecture...

> (2) a replicated file service that runs on all the servers' machines.
>

Hum... Do you meen something close to virtual shares onto CIFS ? Interesting
but probably much more complex to implement.

> I don't really have (1) though venti might get there.
> I know how to do (2) but then I'ld have to handle
> inconsistencies and the solution looks like it'll
> get so dhcp dependent that I should just go with the
> draft standard.
>
> Any comments?  Someone already done it or something better?
> I'm going to start on the draft version but I have nothing
> against stopping or changing it later.
>