[142929] in North American Network Operators' Group
Re: high performance open source DHCP solution?
daemon@ATHENA.MIT.EDU (George Herbert)
Wed Jul 20 20:18:47 2011
In-Reply-To: <1D59D851-2A0E-4CED-BAA5-61FDFD3CF4D0@bogus.com>
Date: Wed, 20 Jul 2011 17:17:55 -0700
From: George Herbert <george.herbert@gmail.com>
To: Joel Jaeggli <joelja@bogus.com>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
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 w=
orkloads 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> =A0=
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 =A0requirement that a DHCP server is to ensure tha=
t any
>>> lease is committed to persistent storage, strictly before a DHCP
>>> server is allowed to
>>> send the response to the request; =A0 a fully compliant DHCP server with
>>> sufficient traffic
>>> is bound by the disk I/O rate =A0of underlying storage backing its data=
base.
>>>
>>> I do not recommend use of a RAMDISK; =A0it's safer to bend the rule tha=
n break it
>>> entirely; =A0 a safer way is probably to use a storage system on a batt=
ery-backed
>>> NVRAM cache =A0that you configure to ignore SYNC() and lie to the DHCP =
server
>>> application, =A0allowing the storage system to aggregate the I/O.
>>>
>>>
>>> Of course, =A0committing 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 =A0DHCP server completes its reboot cycle.
>>>
>>> As a result, you can generate conflicting IP address assignments, unles=
s you:
>>> (a) Have an extremely short max lease duration =A0(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
