dont-use-fsync real world impact

Simon Hobson dhcp1 at thehobsons.co.uk
Sun Sep 29 15:43:56 UTC 2019


Jure Sah <e at juresah.si> wrote:

> I see, so if theoretically the DHCP server could work in such a way as
> to "fsync asynchronously" (oxymoron I know), in that the lease could be
> written to disk before it is offered to the client, but not necessarily
> before the next lease could be served, then this would adhere to the
> RFC, represent no real performance penalty, while also not limiting the
> rate at which requests can be served.
> 
> What changes would be required for this to work? A memory pool of
> offered IP addresses which are not to be assigned to new clients?
> Rotating a pool of physical disks to store leases in? Multiple
> synchronised DHCP servers?


I suspect it would be a very very major redesign of the code. I would guess a multi-threaded server where each thread could handle one request - writing a lease record and responding to the client before being available to handle another request. As long as the lease record were built in a local buffer and written in an atomic write, then lease file integrity would be assured.
I suspect it would need a single thread responsible for arbitrating access to the database - allowing service threads to acquire an address for a client and mark it as in use as an atomic operation to prevent race conditions between competing service threads.

Given that the existing single-thread code can handle large numbers of clients with suitable hardware, and there are methods (see below) for splitting the load if needed, and there are few users needing this level of performance, I can't see this being a good use of developer time. Of course, if you really need something, then the ISC are open to people who will sponsor development work.

BTW - I don't know how much of this applies to Kea, which is ISCs replacement for the venerable DHCP server. Not sure of the status at the moment, but at launch, Kea (while having some advantages) was not feature complete against the older server.


Jure Sah <e at juresah.si> wrote:

> Well I quite disagree, even with SSD RAID arrays, the ultimate
> performance is finite, whereas demands on a DHCP service for instance by
> mobile clients is quite significant and it's easy to have too many
> customers for a single server.

You can have multiple servers on a network.
It's a bit more involved if you have a huge flat network, but that would be poor network design anyway. Particularly if you have multiple networks (different subnets, or more correctly, multiple broadcast domains) then it's fairly easy to have different servers (or pairs) serving groups of networks. You can also have multiple failover pairs, and a server can be in different failover relationships with different pools. You can have (say) four servers on one network, either as simply A-B and C-D with half the available pool configured on each pair, or it can be done A-B, B-C, C-D, and D-A with a quarter of the pool configured on each failover pairing. Particularly with the latter arrangement, you can reduce overlap on DHCP-Discover messages by getting one half of each pair to ignore clients until they have been trying for a certain time, or perhaps using Agent-CircuitID (at the expense of more processing).
In the past, one rather ingenious idea was to have a local server at each access point (the specific case in mind was a distributed wireless access system where access points did not necessarily have battery backup) - with no permanent storage. Each of these servers has a failover pairing with a central server. Normal operation is handled by the remote server using RAM-disk for very fast storage with failover (which is async) providing a backup to the central server. If the remote server fails or has maintenance etc, a relay agent can be turned on to allow the central server to handle clients, and the remote server can reload it's database from the central server using the failover protocol when it restarts. This does, however, trade off a certain amount of risk in that there is a window between local operations and the result being reflected via failover in the central database.

So a few options there.



More information about the dhcp-users mailing list