Re: high performance open source DHCP solution?

[George Herbert <george.herbert () gmail com>]

Good luck buying X25-Es; they're out of production and all gone from
supply chain.  Replacement 710 and 720 models are ETA in late August
at the moment.

Micron has some large-cap SLC drives in the chain for
September/October/ish timeframes.

Ramdisk with rsync or rdiffbackup to spinning storage will do just fine.


-george

On Wed, Jul 20, 2011 at 4:01 PM, Joel Jaeggli <joelja () bogus com> wrote:
> On Jul 20, 2011, at 3:37 PM, Walter Keen wrote:
>
> > We've recently setup ISC DHCPd with failover for lease information, and
> > LDAP as a configuration source (mostly because of our need for
> > dynamically adding dhcp reservations for cable modems, etc) -- we don't
> > have any performance issues thus far, but I'd imagine in a failover
> > environment, it might be safe to consider a ramdisk for leases.
> > Obvoiusly breaks RFC2131, but...
>
> Use an ssd, all the cool kids with monolithic databases and tpc-c style workloads are doing it and since your storage 
> requirements are negligible it ought to be fairly cheap.
>
> http://www.intel.com/design/flash/nand/extreme/index.htm
>
> Bandwidth Sustained sequential read: up to 250 MB/s
> Sustained sequential write: up to 170 MB/s
> Read latency 75 microseconds I/O Per Second (IOPS)
> Random 4KB Reads: >35,000 IOPS
> Random 4KB Writes: >3,300 IOP
>
> and that's for just one disk.
>
> > Walter Keen
> > Network Engineer
> > Rainier Connect
> >
> > (P) 360-832-4024
> > (C) 253-302-0194
> >
> >
> > On 07/20/2011 03: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



-- 
-george william herbert
george.herbert () gmail com

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