Re: [9fans] DHCP

[Sam Hopkins <sah@softcardsystems.com>]

Disclaimer: I admit I haven't been following this thread fully.

I'm just curious, but is this a solution to an experienced problem
or just an exercise in "let's implement this rfc because no one
else has?"  I'm a small shop, but we certainly haven't had problems
losing our dhcp server ... unless the cpu server loses power, in
which case we're pretty much sunk anyway.

Surely if it's the latter, your time would be better appreciated
on solving one of the frequent questions posted to the list
(video card, web browsers, et al).

I'm a big proponent against overly complicating things based on
a *perceived* notion of necessity.

Cheers,

Sam

On Wednesday 19 June 2002 08:45, you wrote:
> ----- 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.