Re: high performance open source DHCP solution?

[Joel Jaeggli <joelja () bogus com>]

On Jul 20, 2011, at 6:25 PM, Owen DeLong wrote:

> SSDs can be a good alternative these days as well. Some of them have gotten
> to be quite fast. Sure, you'll have to replace them more often than spinning media,
> but,

Actually the the scale of writes associated with this application is unlikely to significantly impact the service life 
of an SLC nand ssd with a solid block shadowing/wear leveling implementation. back in 2007 I was convinced that we 
could improve on the reliability of our network appliances with industrial 2.5" sata and enterprise sas disks, and the 
situation has only improved since.

> the write times can be quite a bit better.

like orders of magnitude.

> Owen
>
> On Jul 20, 2011, at 3:28 PM, Jimmy Hess wrote:
>
> > On Wed, Jul 20, 2011 at 9:31 AM, Nick Colton <ncolton () allophone net> wrote:
> > > We were seeing similar issues with low leases, moved the dhcpd.leases file
> > > to a ramdisk and went from ~200 leases per second to something like 8,000
> > > leases per second.
> >
> > Yes, blame RFC2131's  requirement that a DHCP server is to ensure that any
> > lease is committed to persistent storage, strictly before a DHCP
> > server is allowed to
> > send the response to the request;   a fully compliant DHCP server with
> > sufficient traffic
> > is bound by the disk I/O rate  of underlying storage backing its database.
> >
> > I do not recommend use of a RAMDISK;  it's safer to bend the rule than break it
> > entirely;   a safer way is probably to use a storage system on a battery-backed
> > NVRAM cache  that you configure to ignore SYNC() and lie to the DHCP server
> > application,  allowing the storage system to aggregate the I/O.
> >
> >
> > Of course,  committing to a RAMDISK tricks the DHCP server software.
> > The danger is that if your DHCP server suffers an untimely reboot, you
> > will have no transactionally safe record of the leases issued, when the
> > replacement comes up, or the  DHCP server completes its reboot cycle.
> >
> > As a result, you can generate conflicting IP address assignments, unless you:
> > (a) Have an extremely short max lease duration  (which can increase
> > DHCP server load), or
> > (b) Have a policy of pinging before assigning an IP, which limits DHCP server
> > performance and is not fool proof.
> >
> > --
> > -JH
> >
> > _____
> > NANOG mailing list
> > NANOG () nanog org
> > https://mailman.nanog.org/mailman/listinfo/nanog
>
>
> _____
> NANOG mailing list
> NANOG () nanog org
> https://mailman.nanog.org/mailman/listinfo/nanog


_____
NANOG mailing list
NANOG () nanog org
https://mailman.nanog.org/mailman/listinfo/nanog