From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <011f01c21790$e424c660$07cf2bd4@335400> From: To: <9fans@cse.psu.edu> References: Subject: Re: [9fans] DHCP MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit Date: Wed, 19 Jun 2002 14:45:26 +0200 Topicbox-Message-UUID: b38dbb44-eaca-11e9-9e20-41e7f4b1d025 ----- Original Message ----- From: > 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, > > > 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. >