[Maintain] More than two DCHP servers

Greg Connor gconnor at sgi.com
Fri Jun 24 16:24:09 PDT 2005


I'm seeking any advice and feedback for the maintain/dhcp changes we need to 
make.  I will be making the changes myself, and I want to do so in a way that 
others can take advantage of it (and the code can be merged into Maintain code 
base at some point.)

Since we are geographically diverse, we would like to have a total of 4 dhcp 
servers.  (There are considerably more than this now; we will be combining a 
lot of existing servers under Maintain's umbrella to make this happen.)

dhcpd is capable of this - basically the normal failover peer "dhcp" statement 
would be modified to say failover peer "blah" where "blah" is a section in the 
peer file that says what the failover scheme is. (The scheme could be 
something like "dhcp1-dhcp3" to indicate that dhcp1 is the primary and dhcp3 
is the secondary.)

The scheme that I have seen used by others, which we will probably use, is 
something like this:
dhcp1 - primary for ALL ranges
dhcp2 - secondary for region 1
dhcp3 - secondary for region 2
dhcp4 - secondary for region 3
etc.  Although dhcp1 does not need to be primary for all ranges, this will 
help with things like monitoring and viewing lease status.

In order to pull this off, I need to do the following:

1. Mark subnets according to which server will be primary or secondary for it.
2. Write multiple failover peer sections into each peer file.
3. Allow for configs to be pushed to a list of servers, not just one primary
    and one secondary
4. Produce multiple dhcpd data files, because dhcpd doesn't know how to ignore
    ranges that it isn't primary or secondary for.


The part that I haven't decided (and could use some advice on) is how to 
represent the primary/secondary scheme in Maintain's web interface (and 
database) so that it's easy to understand and manage.  If you are interested, 
check out the ideas below and see how you feel about them...

A. Minimal additions: add a field to subnet or range

  - Add a field under subnet or range which determines the "peer scheme".  It 
defaults to "dhcp" but could be something like "dhcp1-dhcp3".

  - Minimal changes to config and Maintain.pm to generate multiple data files, 
e.g. dhcp.conf.data.dhcp1-dhcp3, and to ship them to a number of servers. 
When creating the various peer files (one per server) the administrator would 
also modify the main conf file for each server to manage the include 
statements.

  - Administrators would enter the "scheme" as a field when creating the 
subnet.  To move subnets to a different server, edit the subnet and change the 
scheme.


B. Use "workgroups" to collate data for each region, including failover

  - Allow subnets to be associated with workgroups.  (Currently workgroups are 
associated with hosts, but not subnets.  dhcpd allows subnet{} sections to 
live in group{} sections, and to inherit dhcp options from the group, but 
maintain currently doesn't take advantage of this)

  - Limit would be one workgroup per subnet, but many subnets may share the 
same workgroup.  If not explicitly chosen, subnets would belong to the Default 
workgroup.

  - Each workgroup would have a dhcpd scheme.  (can be the same as other 
workgroups, for example "Midwest" and "West coast" may have different dhcp 
options but the same failover scheme)

  - In larger environments, there would be fewer dhcp options to manage 
overall.  (For example, "West coast" workgroup can have the dns servers, 
netbios, and domain name, and the subnets inherit these options; the subnets 
then only need to have default router option)

  - To make changes for a region (such as adding a new dhcp server) you don't 
need to edit each subnet, only the workgroup.


Personally I am leaning toward option B, because it would have some other 
scalability features besides just failover.  However, I wanted to bounce it 
off other Maintain users, to see if there is sufficient interest, and no major 
barriers to adoption that I'm not seeing.  I'm interested in whether you would 
use the features in option B for other things besides failover.

Q. If A and B were offered as patches, might you take A, B, or neither?

Q. If such a patch is interesting, would you be interested in testing the 
patch and providing feedback?

Q. Would you have any problems or concerns with A being merged into Maintain? 
Are there any advantages or problems with A not expressed above?

Q. Would you have any problems or concerns with B being merged into Maintain?
Are there any advantages or problems with A not expressed above?

Please answer either on-list or privately to me, at your option.  I will 
collect any replies sent to me and summarize back to the list, though if you 
would like to take the ideas further and get discussion and feedback on your 
ideas too, by all means reply-all...

Thanks for taking the time to read.
gregc
--
Greg Connor <gconnor at sgi.com>
Netops Services Group


More information about the Maintain mailing list