high performance open source DHCP solution?
Joel Jaeggli
joelja at bogus.com
Wed Jul 20 23:01:22 UTC 2011
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 at 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 at nanog.org
>> https://mailman.nanog.org/mailman/listinfo/nanog
>
> _____
> NANOG mailing list
> NANOG at nanog.org
> https://mailman.nanog.org/mailman/listinfo/nanog
>
More information about the NANOG
mailing list