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 <ncol...@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
