Re: [9fans] DHCP

Re: [9fans] DHCP

[ynl]

Just curious. Why now? Is it related to tying dhcp leases to
dns entries?

- ynl

Re: [9fans] DHCP

[presotto]

I was about to get rid of all static addresses at the labs.  We currently
are sure to come up after a power failure because we have multiple
stand alone systems, one of which usually works after power returns.
We currently run dhcp without dynamic addresses on one stand alone
server and with dynamic address on two of the systems running off of
shared file server.

If I get rid of statics, I need some way to sync the stand alone
server with the others.  I don't like any of my proposed solutions
so for now, I'm just going to have any non stand alone systems
bind /lib/ndb/dhcp from the standalone and use that as the state.
I need to rig something to rebind and restart those servers if
the stand alone reboots, but that's no bid deal compared to
maintaining synchronized state.

[9fans] DHCP

[presotto]

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.

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.

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
(2) a replicated file service that runs on all the servers' machines.

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.

Re: [9fans] DHCP

[plan9]

----- 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.
>

Re: [9fans] DHCP

[Sam Hopkins]

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.