[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